DevOps for Microservices
Microservices is a new design strategy that is generating a considerable amount of interest and excitement. Many large monolithic systems have inherent complexities due to the abundance of moving parts—each of which could create some challenges during deployment. Microservices addresses the challenges of deploying these bulky, complex monolithic systems.
While some folks view microservices as a much-improved service-oriented architecture, there actually are significant differences in strategy and approach necessary for efficient build, package, and deployment. In my work as a DevOps engineer, I often have conversations with engineers tackling the microservices approach, which I see as an evolving strategy, albeit one with considerable potential and substantial considerations from a DevOps view.
Microservices involves a number of design principles, including design aligned with business services and complete encapsulation of the service so that the component can be deployed as a whole. Developers adopting this strategy design the service to be completely self-sufficient so that there are no external dependencies, such as an external shared database. As one developer explained to me, “Each microservice must contain its own internal persistence layer”—which is certainly different from deploying components that share an external relational database. Microservices may require tradeoffs but is viewed as having significant potential scalability.
As a DevOps engineer, my role is to effectively partner with both development and operations to ensure an efficient and reliable approach to application build, package, and deployment. To accomplish this goal, I need to understand the technology in order to help find the best approach to writing the deployment automation. I also need to understand how the service will be operated in production so that I can help support application deployment from an operation viewpoint, which includes environment monitoring, rapid patch deployment, and even reverting to a previous release if necessary.
My view of DevOps includes all the stakeholders in the ALM, including the business or product manager, and it turns out that the business view is essential for modeling microservices in alignment with business services, which is a core requirement in this approach. Microservices also has some significant continuous testing requirements that are essential for keeping up with the frequent demands for continuous delivery and continuous deployment.
I am very skeptical as to whether microservices is going to really reach its full potential. I also think the tradeoffs may make this approach more of a continuum than a strict set of guidelines. Honestly, I can automate an application build, package, and deployment of a monotlithic system just as well as I can automate a microservice deployment.
But what I am enjoying is partnering with all the stakeholders in the ALM as we take this journey together to see if microservices is really effective and scalable. If you are a DevOps engineer, make sure you are an active participant and enjoy the benefits of helping to design and implement new strategies and approaches.
