When a company embarks on “digital transformation,” it often has to modify its existing software systems. This can become excruciatingly difficult in large organizations with software monoliths—large, custom-built software systems with multiple development teams working on the same codebase.
A common response from companies with their backs up against the “monolithic wall” is to hire executives from well-known tech companies like Google, Microsoft, Amazon and others to “digitally transform” them. This often involves replatforming to a new architecture that leverages microservices and APIs.
(Related: Microservices and scaling out Big Data)
Frequently, when this new technical leadership comes in, they bring their most trusted developers with them. (I personally experienced the same at Dell, where I, an ex-Amazonian, and other leaders from BEA, eBay, Microsoft and Amazon set out to transform their e-commerce experience.)
This can help speed up the transition to microservices, but there’s also a shelf life to how long good developers are willing to stick it out. If the monolithic stack doesn’t go, the good developers will.
Trouble is, monoliths are notoriously pesky, and replatforming isn’t always as easy as it seems. At the end of the day, the transition to microservices has less to do with technology and more to do with managing people and vendors. Leaders who think they can build new software and avoid touching legacy systems and confronting organizational roadblocks are fooling themselves. There’s simply too much inertia to avoid these challenges and replatform to a new architecture the right way.
While failure to make the transition can amount to career suicide, recognizing the real challenges can lead to success.
Embracing vs. resisting change
A change leader should first recognize that not everyone in their company is willing to accept change.
Like it or not, there will always be two groups of developers in your organization: Those who embrace and drive change, and those who resist it at every turn. Competent and well-intentioned as this latter group may be, changing their attitude to follow the new microservices model is a cultural shift that must happen—and sooner rather than later.
Often, this shift involves long, painful meetings, and sometimes even letting people go. Even Amazon, the poster child of service-oriented architecture, required a top-down directive from Jeff Bezos before turning the corner.
The best way to overcome this is “leading by example” by having those early adopters roll out a few microservices and show that they are indeed easier to operate and develop than monoliths. Areas that may immediately chafe existing developers and operations members are concepts such as “developers doing operations,” or that each microservices team is responsible for both the “operational” and “business” success of their own service.
Taking control of your own software stack
Entrenched software vendors of web application servers, ESB and virtualization technology often drop roadblocks in front of technical leaders when the only choices for building microservices are open-source and cloud-native technologies. These vendors may pair up with “change resisters” within an organization to block change.
To avoid this, leaders should try to give their early adopters carte blanche control of the stack and simultaneously negotiate down the cost of their entrenched software vendors. Negotiating down costs, or eliminating them entirely, can be used to fund the “new” software stack or other efforts such as automation.
Cloud migration imperative
Microservices require a significant increase in capital and operating expenditures (CAPEX/OPEX) because each microservice needs its own cluster of servers to run on. The move from monoliths to microservices means the number of clusters required to run a microservices architecture might increase the number of servers by 10x, or even 100x. Without moving to the public cloud, or transforming the data center to run cloud-native technology like Cloud Foundry, the CAPEX/OPEX costs can be totally prohibitive.
With this in mind, IT leaders should set expectations with finance that upfront investment is necessary. In some cases, this investment is spent on setting up a public cloud instance. In others, it is spent on transforming existing data centers with platforms like Cloud Foundry. The second part of investment is on infrastructure automation so that it becomes cost effective to manage all these microservices at scale.
Make fear your ally
When it comes to migrations, fear sometimes works better than encouragement. To kill the monolith at Amazon, another edict came down dictating that whichever team failed to decouple themselves from the monolith would end up owning and supporting the monolith. No developer in their right mind wants to own a bunch of code that was written by someone else, so the right incentives were put in place for the transition.
Taking into account the organizational challenges of moving to microservices is just as important as the technical challenges. But with just a bit of upfront thinking and planning, most enterprises can navigate this transition with a lot less pain and angst.
