The introduction of microservices in IT impacts deeply ingrained culture and breaks down the barriers between IT development and operations. This signifies a movement away from the traditional IT development and IT operations into DevOps.

In the previous blog of this five-part series on microservices, we countered the common contention that microservices is simply “SOA done correctly.” In this final segment we will show that a microservice is not simply a new thing to develop using the same methodologies that worked for building monolithic applications. On the contrary, radical change is required in order to succeed with microservices.

Adopting a microservices style of architecture does have its challenges. A traditional enterprise IT department has created a separation between development and operations—and for very good reasons. When developers are allowed to use “the right tool for the right job,” the cost or complexity of operating a system composed of many technologies often isn’t taken into consideration.

Over time, IT operations has standardized on the technologies it owns. This ensures that budgeting for capacity, daily operational tasks, planned upgrades, security and so on can be managed in the most efficient manner, using the least amount of human capital.

Developers need to consider which database, messaging technology, Web servers, app servers, and even operating systems and hardware are used in their production systems. Developers unfortunately have the daunting task of understanding business requirements and, at the same time, they are constrained by what technologies the operations teams agree they can support due to budgetary concerns.

For microservices to become an effective style of architecture, it necessitates a disruption within the overall organization such that the developers who built the system play a much larger role in operating it as well. Interestingly, this notion of developers operating the production system is not entirely new. If we think back to a few decades ago, this was typically the case, but for a different reason. At that time the complexity of running a data center was something that only highly trained engineering scientists could do, and they were typically the same staff that built the applications.

The introduction of microservices in IT breaks the barriers between Dev and Ops. So, before any company goes too deep into microservices, it must step back and ask whether it’s also ready to break down that traditional barrier.

I hope this five-part series has helped clarify what microservices are (and are not), why this new approach came about, and what an organization might need to consider before adopting this exciting new approach to application development. For more information please visit LINK.

The post Microservices: Where Development and Operations Meet appeared first on Reality Check.