Armin Sestic - Fotolia
Technology innovation is often hampered by fast-moving waves of hype that confuse senior management with benefit claims that can't be met early in a technology's evolution. Microservices really took off as a concept in 2016 and have been vulnerable to premature expectations.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Fortunately, a number of factors have relieved a lot of the pressure on delivering results, and microservices may have had more impact already than some technologies have had in decades.
Containers and cloud
One major development was the association between microservices and both containers and private clouds. Enterprise private clouds have drawn from public cloud technology, which imposes a fairly large overhead to assure tenant security. Containers -- and, in particular, Docker -- presented businesses with a lightweight way of virtualizing server resources, one that could efficiently run dozens of lightweight components on a single server. Since the microservices framework is made up of small components, the fit was perfect.
The combination of microservices and containers promotes a totally different vision of how services change application development. In the past, we've expected monolithic applications to morph first into service-based applications and then evolve into smaller services -- microservices. Now, there are signs that new applications could adopt a service-based model but focus first on microservices. The reason is that good microservice development practices ensure that they'll scale dynamically in the cloud and also facilitate component reuse.
Another significant microservices development in 2016 was the growing acceptance of the notion that microservices were stateless. One of the challenges of distributed cloud applications is making sure that multiple applications or users don't try to use the same resources at the same time. Applications that hold data between successive messages are stateful, and they're susceptible to this kind of destructive collision. Because microservices are designed to be used by many different applications and users, they are built to be stateless, which promotes a model of component development that's useful not only in a microservices framework but also in thread or stream programming.
We saw evidence of this stateless mindset in 2016. By the end of the year, development conferences were addressing the idea of using functional programming in a microservices framework. Functional programming generates naturally small atoms of code, and the languages almost dictate stateless design. We may see the symbiosis between functional programming and microservices emerge as a major driver to new development practices.
Issues of misuse
Not everything that happened in 2016 was positive. The most challenging new issue was the risk that microservices would outrun tools and skills and be misused. Part of this problem arises from the positive linkages of microservices to containers, functional programming and stream programming. All of these developments are still being absorbed by enterprise programming teams, and the fact that they also encourage microservices expands the scope of changes that architects and programmers face.
We learned in 2016, for example, that a microservice application deployed in containers and taking full advantage of scalability is difficult to design because of the variability in performance that could arise depending on just how the microservices used are deployed at a given moment. Latency is rarely a major problem in directly coupled components, but it can completely break an application if components are inefficiently coupled over a network. And the more components there are, the worse the problem can be. Even deciding what latency might be and controlling it in design is difficult.
Even greater problems can arise when users report poor performance or outright failure. An application that depends on a whole set of distributed components, some of which exist in multiple copies and require dynamic application of work, is totally outside the experience of most operations specialists. Even determining the actual components involved in servicing a given user may be difficult, and when you look at current workflows, you can almost expect that the pattern you see isn't the one that prevailed moments ago when users noticed the problem.
Critical design considerations
What real user microservices experiences have shown this year is that traditional tools and practices for application design, application lifecycle management and deployment/redeployment have to be updated or at the least used differently. One thing that became very clear is that API management and API gateways are not only critical to using microservices, but critical in insuring that security and compliance goals are met and that applications run stably and predictably. The microservices trend is establishing API management and API gateways as critical elements in application design and management, even extending beyond the scope of microservice adoption. But despite the interest in microservices, this practice was far from universal in 2016.
In fact, microservices are far better represented in blogs and the media than in enterprise applications. Experience in microservice design is limited, and software architects in particular have failed to ensure that microservice-componentization is adopted only where benefits outweigh the costs. Many early attempts at microservice-based applications have failed because the attempts were simply badly targeted. That targeting problem will have to be fixed in 2017 and beyond.
The sum of the state of microservices in 2016 is both positive and negative. We learned how to apply microservices to new developments, where microservices can promote efficient programming practices and fully realize the agility and elasticity of the cloud. We also learned that microservice-based development not only imposes different rules on development teams, but also imposes different rules on operations personnel and impacts the entire application lifecycle management flow. Most of all, we learned that migrating current applications to a microservices framework can be a major challenge. How far we can take microservices in the future will depend on how well these challenges are met, and whether the positive results microservices have brought can extend to cover the risks.
How to avoid redundancy in microservice design
How to implement holistic governance, risk management and compliance for microservices
Why the benefits of microservices aren't so easy to realize
Dig Deeper on Microservices and DevOps