Once organizations and their development teams have mastered agile and DevOps, the next step is to look at what software architecture is the best fit for DevOps.
DevOps introduces automation into operations with continuous delivery. However, the benefits of rapid change in production can only be realized if it is possible to make these changes with minimal disruption. Large monolithic systems need to be taken down before changes can be made, creating delay. So, in this respect Microservices architecture (MSA) is an ideal fit.
It has many other benefits as well:
- It allows systems to scale horizontally efficiently;
- It allows development to be scaled effectively as project size grows;
- It introduces event-driven computing which can exploit serverless computing;
- It makes it easy to mix programming languages and technologies (polyglot feature) as microservices are highly decoupled;
- And it is a natural path to cloud native computing.
Microservices architectures also have a downside: the degree of overhead in running it is higher than monolithic for small projects, only switching over to being lower than for monolithic for high internet-scale usage and highly complex applications. It is also a novel technology for many developers and experience in designing it well is still limited. Martin Fowler, chief scientist at ThoughtWorks, advocates building a monolith first, and if it proves necessary, transforming it into MSA. Starting to build MSA from scratch is fraught with pitfalls. Even with experienced developers building the first version of a system is still a learning experience, for both developers and business stakeholders. There is a lot to be said for throwing away the first version, even as far back as Fred Brooks Jr., who wrote in his seminal 1975 book, “The Mythical Man-Month,” that pilot systems are essentially “throw-aways.”
MSA technology is also evolving. 2017 saw the emergence of the service mesh, with open-source projects such as Envoy and Linkerd, operating at the data plane. 2018 will see a new type of service mesh gain adoption, that includes both data and control planes, e.g. Istio and Conduit. The service mesh makes working with MSA a lot easier, by removing the need for developers to build communications ‘plumbing’ between services. With a service mesh every microservice now has a proxy network server or ‘sidecar’. All communications are channeled through the proxies. There are multiple benefits in using a service mesh, but it will encourage a better and easier style of building MSA.
As a final thought, the emergence of many new styles of building software applications today, and the huge benefit that open source software has introduced, has created a large gap between developers at the lead of building with these technologies, and the many others in enterprises that are still struggling with agile and DevOps transformation. The gap between the leaders and the rest has widened considerably compared to say the 1990’s. That’s not saying it is bad, just highly noticeable.