Anybody reading all the hype about microservices is going to walk away thinking one thing: Too good to be true.
Applications and networks that are faster, cheaper, and higher quality? C’mon, pull my other leg now.
No matter what the technology, no Big Change comes easily, quickly, or cheaply. That’s not just because of your need to maximize the return on your existing technology investments. There will always be an accompanying need for new skills, whether retraining current employees, hiring new ones, or going the services route.
According to Sequoia Capital’s Matt Miller in a January 23, 2016, article on TechCrunch, microservices’ most distinguishing characteristic is specialization. Today’s large, “monolithic” applications are replaced with apps comprised of many distinct, interchangeable parts. These “loosely coupled… autonomous pieces” are the key to making development faster, more efficient, and less expensive. The pieces are assembled in the software equivalent of the production line.
The biggest names in tech have been using microservices for years. They include Google, Amazon, Airbnb, Disney, Dropbox, and Twitter. Miller compiles the noteworthy lessons learned by early adopters of microservices, first and most important of which is to determine whether a particular app justifies paying the “microservices premium.”
The evolving microservices ecosystem, as presented by Sequoia Capital.
When an app reaches a certain level of complexity, the microservices approach introduces so much overhead that costs soar and performance sinks. Before you can expect to realize the benefits of microservices, you need to have continuous delivery and automated processes in place. Proponents recommend that you start small, match the process to your business’s characteristics, and build on your early successes.
As more apps are converted to microservices, it may help to create a shared repository of services to avoid having multiple active versions of common services. Monitoring becomes more of a challenge as the number and complexity of your microservice apps increase.
Laying the groundwork for a gradual transition to microservices
A prerequisite to adoption of microservices-based applications is the switch to a DevOps model of IT management, according to Computer Weekly’s Danny Bradbury in a February 2016 article. An incremental approach to microservices adoption is supported by the many plug-ins offered by cloud services for connection to in-house data centers.
For example, a company with an extensive distributed inventory management system wouldn’t attempt to re-engineer the entire application for microservices, but it could create enhancements to the system based on container-based microservices that integrate smoothly with existing functions. It is important to find purposes that benefit from quick code turnaround and continual innovation, such as mobile applications.
In fact, adoption of microservices and the transition to DevOps go hand-in-hand, according to analysts. Developers and operations staff have to work together throughout the development, testing, deployment, and update cycle. The days of hand-offs are over, which means when a code problem is discovered at 2:00 a.m., the developer is just as likely to receive the alert as the operations staffer. The potential IT culture shock is another reason to plan a deliberate, step-by-step transition to microservices.
APIs are the glue that bind the many specialized services and other distributed components of the microservices architecture. Source: Integration Works
A lesson in how not to implement microservices
In an August 25, 2015, post on InfoQ, Vijay Alagarasan recounts how one organization used a services approach to develop and deploy a claims platform that ultimately crashed and burned. The resulting application worked as expected upon initial deployment, but despite being engineered to support many incremental updates and frequent redeployments, the system collapsed under its own weight.
Once in production, the app was updated 10 times more frequently than occurred with the initial implementation. The resulting functional testing and release cycle slowed updates to a crawl, leaving users waiting for the features they needed to realize the promised productivity boost. The system was unable to scale as functions unrelated to its core purpose were added haphazardly, usually at the request of “influential” customers.
To avoid getting bogged down in feature creep – the enemy of agility – an arbiter is required to exclude any functions being glommed on that aren’t directly related to the app’s core purpose. Without functional separation, the agility, performance, and scalability promised by microservices cannot be realized.
Other requirements for microservices to thrive are to create an environment that supports continuous deployment, eliminate out-of-process calls in your layered architecture, make sure your services are independent (updates don’t rely on outside approval), automate configuration management, plan ahead for smooth implementation of new versions, and use an API gateway to facilitate orchestration of services and other components.
