{"id":390609,"date":"2018-01-30T11:01:39","date_gmt":"2018-01-30T10:01:39","guid":{"rendered":"https:\/\/www.devoteam.com\/news-and-pr\/is-your-organization-ready-for-microservices\/"},"modified":"2018-01-30T11:01:39","modified_gmt":"2018-01-30T10:01:39","slug":"is-your-organization-ready-for-microservices","status":"publish","type":"news-and-pr","link":"https:\/\/devoteam.info\/en-nl\/news-and-pr\/is-your-organization-ready-for-microservices\/","title":{"rendered":"Is your organization ready for Microservices?"},"content":{"rendered":"

It hasn\u2019t gone unnoticed that Microservices are the next big thing companies are looking into. We are often asked by our clients to explain and demonstrate some of the benefits of Microservices and in some cases this has proven rather a challenge. <\/b><\/p>\n

Why is it a challenge? Not because it is hard to prove the value of adopting Microservices, there certainly is value in this, but rather showing our clients how this architecture style could fit the organization.<\/span><\/p>\n

“Microservices is not just an architecture style, but also an organizational structure. Adopting the one without the other is like buying new running shoes and wearing them just to watch Netflix.<\/span>“<\/em><\/p><\/blockquote>\n

The post-SOA era<\/span><\/h2>\n

Despite all media hypes on Microservices, many organizations have only recently put the \u2018Service Oriented Architecture phase\u2019 behind them. These organizations are looking at their Enterprise Service Bus with mixed feelings. Its promises that SOA would bring loosely-coupled interfaces that could support reuse and provide shorter time to market: they didn\u2019t really pay out. It still takes a significant amount of effort and labour to make seemingly small changes let alone develop new products. Chances are that the same old monolith that existed before the Enterprise Service Bus is still humming in the datacenter.<\/span><\/p>\n

Why would Microservices work now?<\/span><\/h2>\n

So why did these promises not work out for these organizations? One theorem, the one proposed here, is that the organization wasn\u2019t aligned and therefore not everybody was in on the game. More bluntly: the team that developed the services on the ESB was not the same that developed corresponding features on the monolith. And the same goes for the smaller monoliths. <\/span><\/p>\n

This separation of ownership and responsibility is sometimes referred to as \u2018Design by Committee\u2019, and has lead to suboptimal results. Nevertheless, it was a best practice which was often formalized in an \u2018Integration Competence Center\u2019 or such.<\/span><\/p>\n

Microservices do offer a solution to this caveat and they do so by organizing around business functionalities rather than technologies. The old \u00a0Unix philosophy \u2018do one thing and do it well\u2019 certainly applies to Microservices where the aim is to build smaller and clearer bits of functionality that are functioning very well. <\/span><\/p>\n

So, microservices should be developed by the team that has the domain knowledge and will maintain them too (\u2018You build it, you run it\u2019). In case of legacy applications, this team should consist of members of, or actually be the team owning the legacy application. This is to ensure that the domain knowledge required to build the correct and understandable functionality is incorporated into the microservices. With the addition of DevOps and a CI\/CD (Continuous Improvement\/Continuous Deployment) toolchain the team\u2019s set!<\/span><\/p>\n

Microservices: An organizational structure<\/span><\/h2>\n

Microservices are often advertised as an architecture style\/pattern. What is hardly ever mentioned is that the organization needs to be supportive of this style as well. <\/span><\/p>\n

The main takeaway is that Microservices is not just an architecture style, but also an organizational structure. Adopting the one without the other is like buying new running shoes and wearing them just to watch Netflix.<\/span><\/p>\n

For questions about this blog you are able to contact Stephan Ansems, Senior Consultant at Devoteam Netherlands (<\/span>stephan.ansems@devoteam.com<\/a>).\u00a0If you are interested in Microservices as a solution for your business, feel free to contact Ratko Popovski, director Architecture & Implementation at Devoteam Netherlands (<\/span>ratko.popovski@devoteam.com<\/a>).<\/span><\/p>\n

More about Microservices<\/h2>\n

Check out our previous blogposts and white paper:<\/p>\n