Microservices and the Revival of Software Design
By JP Morgenthal

Back in February of 2017, Andrew Clay Schafer of Pivotal tweeted the following: “seriously tho, the whole software industry is stuck on deployment when we desperately need architecture and telemetry.” Intrigue in a 140 characters. For me, I hear Andrew saying, “we’re jumping to step 5 before we’ve successfully completed steps 1-4.”

I have to agree with Mr. Shafer that it does seem like the IT industry has a fascination with the part of the process that releases new capabilities into production. I personally hear the words “continuous delivery (CD)” at least 3-4 times a day. However, CD is the result of multiple iterations on a delivery pipeline to remove bottlenecks and consistently optimize and improve. Enterprises that believe they can get this right on the first attempt will be at a very high risk for failure.

I believe a key driver enabling users to make this leap is the emergence of the microservice. Because microservices embody both engineering and operational elements within its design, it’s possible for businesses to just focus on the operationalization of a microservice without even requiring any engineering effort. For example, operations can take an existing application component and package it up in a container (e.g., Docker) and deploy ten instances of that container.

This now suffices in some businesses as a microservice. However, it’s not really a microservice, it’s just a repackaged application component that now is easier to manage and deploy. I don’t mean to belittle this effort. The ability to automate management and deployment of existing applications goes a long way to reducing IT overhead. However, to Andrew’s point, it’s missing the architecture and telemetry.

Microservices: A Key Element of DevOps Strategy
The last few decades of software engineering have heavily emphasized design without equal consideration for operationalization of the software being developed. As a visualization, perhaps you have seen the meme with the young girl and the house on fire in the background with the text, “it worked fine in development.” That’s because it’s easy to make a distributed application work in a properly engineered development environment; it’s when we release it into production (the wild?) that we begin to see its flaws.

The response to the above trend has been the emergence of DevOps and a focus on adopting lean principles that facilitate rapid and continuous deployment of small numbers of changes. The rationale behind this is sound; limit the number of changes in control variables, leverage an automated and highly-repeatable process that has been thoroughly tested to push into production, and lower overall risk.

However, to Mr. Shafer’s point, it seems there is a bit of extremism that has swung the pendulum too much to the side of operationalization without having first mastered the art of the design. I believe the results of this effect can be summarized as moving garbage faster into production. I also believe microservices is an industry response to the need for more design in what we are putting into this pipeline.

All distributed computing archetypes recognize deployment architecture in some way, shape or form, but microservices is really the first of these distributed object computing archetypes to address packaging and distribution as a first-class attribute of the design goals. Isolation, decentralized data management and implicit tolerance for failure are central design goals for microservices. However, the key is to design the microservices in such a way as to amplify the business value of the entity, fulfilling the second part of Mr. Shafer’s statement.

In the past we have taught architects to think component design. But components are a part of something larger and don’t have value outside of the larger entity. For example, a gear is a component of an engine. The engine needs the gear to operate, but the gear has little value outside of the engine. We must now teach architects to think in terms of designing services, which have innate value without being part of something larger, but still can participate in a larger context, increasing it’s value. Hence, the service can be part of a larger application, or it can simply deliver on a single goal.

Microservices, then, are an integral and key element of any DevOps strategy. It is a common model that application development and operations can share and clearly establishes deployment boundaries and pathways. For engineering, the microservice represents a bounded set of business logic and data supporting a business capability. For operations, the microservice represents the unit of deployed business capabilities.

The post Microservices and the Revival of Software Design appeared first on XebiaLabs.