Microservices Are a Commodity

I'm a big fan of Simon Wardley. I'm not able to follow everything he writes about, but even the old writings are very interesting and somehow it all makes sense in retrospect. If you haven't read anything from him, this video is an excellent start (or go back a few years to the longer talk). In this article, I'll try to make sense of what is happening in the microservices world using Wardley's theory (and diagrams).

How Have Things Evolved?

Any idea, product, system, etc., starts with its genesis. If it is successful, it evolves, and others copy it and create new custom solutions from it. If it is still successful, it diffuses further and others create new products that get improved and extended and become widespread, available, “ubiquitous,” and well-understood — more of a commodity. This lifecycle can be observed in many successful products when looked over the years such as computers, mobile, virtualization, cloud, etc.

If we think about microservices, architectural style, the projects that support them, platforms that were born from it, containers, DevOps practice, etc., each of them is at a certain stage. However, as a whole, the microservices movement now is a pretty widespread, well-understood concept, and it's turning into commodity already. There are many indications confirming that, as seen from the number of publications, conferences, books, confirmed success stories on production, etc. There's no doubt about it; not any longer.

How Did We Get Here?

The microservices genesis started five to six years ago with Fred George and James Lewis from ThoughtWorks sharing their ideas. In the next few months, Thoughtworks did a lot of thinking, writing, and talking about it, while Netflix did a lot of hacking and created the first generation of microservices libraries. Most of those libraries were still not very popular or usable by the wider developer community, and only the pioneers and startup-minded companies would try them at times. Then, SpringSource joined the bandwagon. They wrapped and packaged the Netflix libraries into products and made all the custom build solutions accessible and easy to consume for Java developers. In the meantime, all this interest in microservices drove further innovation and containers were born. That brought in another wave of innovation, more funding, shuffling, and a new set of tools, which made the DevOps theory a practice.

Containers being the primary means for deploying microservices soon created the need for container orchestration, i.e., Cloud Native platforms. Today, the Cloud Native landscape is in transition, taking its next shape. If you look around, there are multiple Cloud Native platforms, each of which started its journey from a different point in time with a unique value proposition and slowly getting into a common feature set with similar concepts and standards.

For example, the feature parity of platforms such as AWS ECS, Kubernetes, Apache Mesos, and Cloud Foundry, are getting close, each being feature-rich, being used in production, and having comparable primitives.

As you can see from the diagram above, now what becomes important as a technology strategy is to bet on platforms with open standards, open source, large community, and a high chance of long-term success. That means, for example, choosing a container runtime that is OCI-compliant, choosing a tracing tool that is based on open-tracing standards rather than custom implementation, and supporting the industry standard logging and monitoring solutions that are supported by companies that have good commodity products.

Organization Types

According to Wardley, there are three types of people, teams, organizations, etc., and each is good at certain stages of evolution:

• Pioneers are good in exploring uncharted territories and undiscovered concepts. They give the crazy ideas life.
• Settlers are good in turning the half-baked prototype into something useful for a larger audience. They build trust and understanding and refine the concept. They turn the prototype into a product, make it manufacturable and turn it profitable.
• Town planners are good in taking something and industrializing it, taking advantage of economies of scale. They build the trusted platforms of the future, which requires immense skill. They find ways to make things faster, better, smaller, more efficient, more economic, and good enough.

With this definition and the above table showing the characteristics of each type of organization, we can make the following hypothetical classification:

• Netflix is definitely the pioneer — the creative pathfinder. The way the company is set around experimentation and uncertainty, their culture around freedom and responsibility, and everything they have brought into the microservices world makes them pioneers.
• SpringSource is more the settler type. They already had a popular Java stack and they managed to spot the trend in microservices, and created a good consumable product in the form of Spring Boot and Spring Cloud.
• Amazon, Google, and Microsoft are the town planners. They may come late, but they come well-prepared, with the long-term strategy defined, web-scale solutions, and unbeatable pricing. Platforms such as Kubernetes and ECS (not entirely sure about the latter as it is pretty closed) are built on over 10 years of experience and are indented to last long and become the industry standard.

One important takeaway from this section is that not everything invented by pioneers is meant for general consumption. Pioneers move fast, and unless your organization has similar characteristics, it might be difficult to follow all the time. On the other hand, town planners create products and services that are interoperable and based on open standards. That, in the longer term, becomes an important axis of freedom. 

Conclusion

In the microservices world, things are moving from uncharted to industrialized direction. Most of the activities are not that chaotic, uncertain, or unpredictable. It is almost turning into a boring and dull activity to plan, design, and implement microservices. Since it is an industrialized job with a low margin, the choice of tools and ability to swap those platforms plays a significant role.

Last but not least, a nice side effect of this evolution is that we should hear less about Conway's Law, the two pizzas, and circuit breakers during conferences, and should hear more about managing microservices at scale, automation, business value, serverless, and new uncharted ideas from the pioneers in our industry.