It’s only been about 25 years or so since Jeff Bezos was selling books out of his garage for a small company known as Amazon.com. Over the next two decades, Amazon and other retailers have gone through many shifts in business, and the most recent is a shift to a more microservice-based architecture.
Monolith Architecture
The word monolith is often attributed to something large and glacial, and that’s not necessarily far off from the software design aspect. This architecture is a singular large computing network made up of one code that encompasses all business needs together.
Like Amazon, many retailers started with, and continue to use, a monolithic approach, where the entire application was built as a single unit. This was successful because it gave businesses a lot of capabilities and a great launchpad to go digital, something they had never done before.
Making a change to a monolithic architecture requires updating the entire stack making many believe that monoliths are restrictive and time consuming. On the other hand, monoliths can be convenient early on in a project’s life for ease of code management, overhead, and deployment of everything at once.
Pros and Cons of the Monolith Architecture
There are many pros and cons when working within a monolithic architecture. The advantages are:
- Easier deployment – there is one major deployment with everything coupled together
- Easier development – with one long code, it’s easier to develop
- Better performance – with a centralized code, one API can do what several APIs do in a microservice
- Simplified testing – testing can be performed more quickly
- Easier debugging – issues are easier to find since everything is in one code
However, there are cons to this style as well. The disadvantages are:
- Slower development speed – these applications are longer and more complex
- Scalability – depending how it’s built, scaling can’t be done on individual components
- Reliability – if an error occurs, it can affect the entire application’s availability
- Barrier to technology adoption – any changes in the framework or language affects the entire application, thus raising costs and lengthening time spent on the code
- Lack of flexibility – limited by the technologies that already exist inside the monolith
- Deployment – while it is easy to do one major deployment, the con is that to make a simply change, the whole thing must redeploy
Microservices Architecture
An analogy often used for microservices is having a large boulder (monolith) and breaking it down into small little pebbles or chunks (microservices – or discrete, atomic applications.).
Developers can build their own features, functions, and capabilities independent of one another and deploy them to an environment – often the cloud – so that they can be made available as soon as they’re ready. These development teams are small, therefore often more agile and nimble.
Pros and Cons of Microservices Architecture
Much like monolithic architecture, there are many pros and cons of microservices. First the pros:
- Agility/flexible scaling – speed, flexibility, and agility increase as there are smaller teams that don’t have to manually test everything
- Continuous development – current users aren’t affected when a new API rolls out
- Highly maintainable and testable – a few thousand lines of code make it easier to experiment and roll back if something doesn’t work thus boosting time to market
- Independently deployable – microservices are individual units that all for quick deployment
- Technology flexibility – users can select the tools that they desire
- High reliability – specific changes can be made without the whole system breaking
However, there are some cons to microservices. They are:
- Developmental sprawl – more services in more places make it more complex and requires a higher level of digital maturity
- Exponential infrastructure costs – less cost-effective as each part costs money
- More organizational overhead – more communication and collaboration needed per project
- Debugging challenges – challenges now lie outside in the environment in runtime production, cloud management, auto-scaling, team competencies
- No standardization – no common platform means differing languages and practices
- No clear ownership – more services mean more teams thus muddying clear communication lines
Microservices vs. Headless Commerce
Often organizations that adopt a microservices approach think that they are operating in the headless commerce space, but that’s not necessarily true. Headless commerce is a version of microservices in that it is API-based, but it also decouples the business logic and the transactional and data aspects of commerce from the presentation tier.
What headless commerce does is allow brands the agility to deliver content such as products, data, and orders to any touchpoint while being able to display it how they like. Microservices enable individual back-end services to be isolated from each other, deployed a la carte, scaled independently, and developed autonomously.
So what’s right for your organization?
Selecting What’s Right for Your Organization
When choosing which approach to use for commerce in your organization, there are a few things to consider.
- You need to honestly know your digital maturity. These decisions often fall into IT leaders’ hands, and they need to be honest with where they are with their capabilities. If you’re not quite there with your digital maturity, consider getting training and mentoring to determine when you will be ready, as moving to microservices from a monolithic entails a transition towards a different technology. It’s a different way of thinking and defining responsibilities.
- You need to understand the operating model and cost. It’s not enough to simply sit in a board meeting and say, “I can deploy code five times a day.” It’s vital to understand what it takes to run with microservices.
- There has to be executive buy-in to the approach you choose. They need to understand that microservices are a re-imagining of how your IT organization works and the culture within the team.
- The organization should be culturally aligned to the paradigm. There needs to be a commitment to a new way of thinking, ownership, and collective responsibility for the API.
- It’s critical to understand what it looks like to maintain and innovate under this new approach. Partners need to consider staff that have implemented this type of approach and lean on them to help plan out everything from steppingstones to a 5-year plan.
- Doing research is important but remember that vendor demos and analyst reports only tell some of the story. They are not actively operating within the system and don’t run their own products and websites.
Conclusion
It is likely that many vendors will move to a microservices approach in the coming years and some monoliths could be disrupted in the market, but that shouldn’t discourage using a monolithic approach. Not everyone is going to change overnight or even make the switch at all. It’s crucial to decide which approach will benefit the market and organization you’re in.
If you’re looking to move to a microservices architecture, Perficient can help build and deploy cloud-native microservices to help create a robust and scalable platform that promotes easy feature deployment to boost customer experience.
