Microservices Architecture: Don’t Go It Alone

At every software Meetup I go to, the word on people’s lips is microservices, microservices, microservices. Start-ups talk about it as a way to demonstrate that they’re doing things using modern approaches. Enterprises want to sound nimble and more agile than people perceive them to be and government or quasi-government institutions want to sound innovative rather than bureaucratic.

The reality is that most companies don’t know what they’re getting into before they start. Microservices is not a tactic to be executed but rather a strategic initiative that has far-reaching implications for not only how the business develops software, but also how it is structured and how it delivers its product or service. It is a commitment to a re-envisioning of the architecture, the software and the business as a whole. As such, it is not to be entered into lightly.

Consider a home renovation. There are small changes that it’s possible to make. Cosmetic changes – new paint, new appliances or a new floor. However, when you begin to make structural changes – you remove or put up a wall, re-position the kitchen cupboards or change the landing of the staircase, you literally change how you use the space, how you move about the home and where you spend time.

Whether rearchitecting a house or a piece of software, most don’t do it alone. For initiatives of this kind, we hire professionals. Even if we’re competent and could do things ourselves, it makes sense from a risk- mitigation and time-efficiency perspective to engage outside expertise – people or firms that have the required expertise and experience. In other words, they’re not doing it for the first time. This saves time and money in missteps.

One of our clients, a large and well-established enterprise in the automotive space had begun the microservices journey. They had experienced architects in-house, had laid out a roadmap for change and had organized an internal hackathon in order to generate innovative ideas. They began redeveloping their platform and felt it wise to bring us in in order to ensure that they were on the right track.

Given the experience of the team, we expected things would be running relatively smoothly requiring only minor tweaks. What we found were incorrect abstractions, a misundertanding of the domain they were tackling and an architecture that was taking them in the wrong direction. The foresight to bring us in conservatively saved our client a half-million dollars in lost productivity, refactoring and potentially a complete re-write. Bear in mind that this was on a small, relatively isolated part of their overall platform.

The consequences of poor architecture and design are that everything that flows from it is compromised. The development team implements the wrong abbstractions, builds the wrong components while the business team makes promises that it can’t keep and hires people that it shouldn’t need. The impact is exponential and gets worse the longer it goes on.

Conversely, a well thought-through architecture can lead to flexible and scalable software, quick wins for the business, strong morale and confidence that the team is going in the right direction without any second-guessing or cause for doubt.

Companies that are in the business of producing software have a lot at stake whether they are building from scratch or re-imagining their application in the light of competitive pressures or architectural limitations. If you’re going to invest in building or rebuilding software, don’t go it alone.

Comments are closed, but trackbacks and pingbacks are open.