Writing about microservices in 800 words or less can be difficult, so this article will focus on the salient points of why this new way to develop applications should be considered. When we speak with customers about cloud computing, one topic always comes up – the scalability of the computing environments. As companies become more accustomed with migrating to the cloud, they have come to understand that having the ability to scale, equates to having more processing power and ultimately, more capacity within the data center. So, how does designing and developing microservices impact the scalability of an application?
As organizations continue to develop multi-tenant applications, designing smaller modules or services and executing them in a clustered environment makes sense. In many companies, deploying a large set of programs to a production environment is a normal occurrence – now think about the possibilities of deploying multiple microservices across 1000s of VM’s, in a self-repairing, self-scaling (up or down) environment. Microservices is a new development approach, where each service has its own URI and can be coded, configured, tested, versioned and run independently or as a part of a larger and coordinated service.
In a traditional design pattern, there is a separation of the application, UI, business and data tiers, with a strong emphasis on the reuse of software components within those tiers. This is accomplished either through shared binaries/scripts or more modern-day package managers. While code reuse has many benefits, it encourages larger frameworks and a common technical stack. Microservices takes a different approach; in that these services only communicate with each other, over well-known protocols and are decoupled without requiring common code. With this development approach, the application is made up of microservices, which are all independent of each other.
Microservices are developed in small cross-functional teams, and can be built with a variety of languages and can be developed in either a stateful or stateless approach. Microservices act independently in either a private or public environment and with this approach, applications can continuously evolve and scale, making the delivery of the application and any new functionality faster than with current development patterns. Each service is written into smaller and independent modules that do one thing well and because of their size, they are easier to debug, version, maintain and continuously release. In a traditional development approach, monolithic sized applications are developed, maintained and released over longer periods of time, thereby seen as not meeting fast changing business objectives.
Aside from the scalability benefits that microservices provide, there are also tremendous gains recognized in the maintainability of the codebase. As microservices continue to be built, smaller services can be an aggregated to form larger microservices, where numerous modules are packaged to compose, orchestrate and direct all the smaller services, thereby creating a façade design pattern that manages the moving parts within the larger microservice. As microservices are deployed, telemetry should be used to determine how these services are running and performing.
Bear in mind that embarking down the microservices development path can impact existing DevOps processes. Like everything, there is a tradeoff. The increased maintainability of your codebase, comes at the expense of more complexity on the operations side and a centralized approach may no longer work. The tradeoff requires that the development team takes on an end-to-end ownership of the service, which includes the deployment, monitoring, operations, and maintenance. On the flip-side, the operational resources become an active part of the development team, and build the automation scripts that run the deployment and operations for the microservice. DevOps resources become an expert in many services and can be integral members on several service teams and microservices become a backbone to make continuous deployments a reality.
Besides, the previously mentioned benefits, another value of a microservice happens when a node fails, and the microservice is redistributed across the cluster. In a cloud service, the virtual machines scale and help in this redistribution; thereby sustaining availability and performance of the application.
Changing the overall development environment from monolithic to microservice shouldn’t be taken lightly, as there are trade-offs, as well as benefits. There are many articles written about this topic, so pick your favorite browser and search for “microservices”, to learn more about the differences. Happy reading (and developing).
Sue Bergamo is a former Boston area CIO and a Technology Strategist at Microsoft. She can be reached at firstname.lastname@example.org.
Bob Jacobs is a Technical Architect at Microsoft. He can be reached at email@example.com
© 2017. All Rights Reserved.
*The content within this article are the opinions of the authors and are not sponsored by Microsoft.