Business benefits of Microservice Architecture
What should an enterprise do if its dated architecture slowly starts affecting the business negatively? What if you are failing to provide your users what they are wanting? What is the best way to redesign a business value?
Successful companies do not aim to increase the software delivery speed for its own sake. They do it for they are obligated by their business growth and speed.
If you are unable to scale your business and give best to your customer, re-platform to a microservices architecture to build a system that is elastic enough to scale out to handle the peak without negatively affecting the user experience.
After reading this article, you will gain considerable knowledge of microservice best practices and their benefits. You will learn this by reading through the experiences of the world’s best innovative enterprises, Amazon, Walmart, and Spotify.
Why Microservices Architecture is Working Worldwide?
A large suite of application is built as a suite of modular service. All of them are small, independent versioned and customer-centric services that have specific business goals, where standard protocols with well-defined interfaces are used for communication between each individual service.
Since each microservice is independently deployed and scaled, they allow firms module boundary, which implies that different services can be written in different programming languages and can be managed by different development teams.
Microservices platforms are considered ideal for businesses that have the need to enable support for a range of platforms and devices, such as the Internet of Things, wearables, web, mobile, or when the company is not sure what kind of devices it will require to support cloud in future.
Benefits of building microservices architecture are tremendous because its functionalities bring the right balance between delivery speed, the safety of systems, and organizations’ growth in terms of functional scope and scale.
As more companies are recognizing (due to an increasingly digital economy) that software development needs to be a core business competency and fast delivery of the solution is essential to defeating the competition, microservice architecture is gaining precedence over other architectural patterns.
Strategic Importance of Blockchain
Since its inception, the technology has been widely associated with finance because of its connection to cryptocurrencies, which made most industries to view Blockchain as a technology reserved only for the fin-tech industry. However, if we explore, we will find that the solicitation of this electronic ledger is much vast than cryptocurrencies.
It is a building block for many industries presently, since it acts as a legitimate ledger data structure. Apart from bitcoins and transaction records, blockchain has many more functionalities, most prominently allowing digital data distribution instead of data copying.
There are no centralized databases in a blockchain. It ensures that no one individual or party in the system has the power to modify or tamper with the data. It also removes the need for a third party or central authority to authenticate or process peer-peer transactions and hence increases transparency.
Blockchain technology has been hailed as revolutionary and can dramatically lower cost, increase speed, and present transparency of all transactions. Take, for instance, a typical stock purchase or bank wire transaction. The transaction can be executed in minutes but the settlement — the ownership transfer of the stock or funds — takes a few business days. This is because the parties have no access to each other ledgers and therefore cannot automatically verify that the assets are in fact owned and can be transferred. A number of intermediaries (i.e. banks, escrow, credit card companies) act as guarantors of assets as the transaction is verified and the ledgers are individually updated. On the other hand, blockchain transactions reside on a public ledger and are not controlled by a central authority. Decentralizing control removes the need for intermediaries and middle-men. As a result, these transactions can be executed and settled between both parties in minutes with verification that is transparent, public, and validated by the network itself. Whether an emergency or just a normal transaction, this is particularly advantageous where the transfer and receipt of funds are required immediately. While this is just one example, these benefits will collectively alter existing business processes, disrupt industries, and create new business models; similarly, as the Internet did during the digital revolution.
Advantages of Microservices for Businesses
The desire for speed (coupled with safety) is a desire for immediate change, which ultimately takes us to microservices.
When it comes to ‘Speed’, microservices architecture provides the following benefits to businesses:
- The agility of small services allows businesses to deliver products, services, and features quickly.
- Composability allows developers to reduce the development time of the solutions and additionally provides supplementary benefit through reusability over time.
Independent deployment of components offers flexible options for prototyping and piloting and addition of new features in production. It reduces the need to require teams to rewrite the whole application of new features.
- Polyglotism quickens technology introduction and increases solution options by authorizing the use of the right tool for the right task.
- The comprehensiveness of system streamlines planning boosts accuracy and increases the speed of adaptability of new resources.
- Organizational alignment of services reduces team ramp-up time and lets the team build complex products continuously.
When it comes to ‘Safety’, microservices architecture has the following advantages over other architectural models:
- Efficiency in the software development system reduces the cost of infrastructure and the risk capacity related to service outages.
- Independent manageability reduces the need for scheduled downtime.
Smaller codebases make maintenance easier and faster saving a lot of development time and increasing productivity.
- Easy replacement of components reduces technical debts that eventually leads to unreliable environments and dated structure. Unparalleled independent runtime scalability leads to software growth as and when the business grows.
- Improved testing allows for the implementation of risk mitigation.
Microservices architecture deployment case studies of the world’s leading Enterprises
Walmart, Canada, Revitalizes a Failing Architecture
Kevin Webber helped to re-architect Walmart’s online business after the retail giant failed to provide its customers on Black Fridays for two continuous years. Walmart, Canada could not handle the six million page views per minute, which made them incapable of providing positive user experience further.
The old architecture of Walmart was based on a 2005 architecture, designed around monoliths, laptops, and desktops. Since they were unable to scale for six million views per minute, in 2012, Spotify had to renew their age-old legacy system and prepare for the 2020 world – a network connection having 4 billion people, 25+ million apps, and 5.2 GB of data for each user. Their aim was a 100% availability achieved with reasonable costs.
And so, they chose to migrate to microservice. They experienced the following changes almost instantly:
- Conversions boosted by 20% just within 24 hours.
- Mobile app orders were up by 98% on the same day.
- The company experienced superb sales on Black Friday or Boxing Day (Canada). It has seen no downtime since re-platforming to microservice.
- But what was most significant was the operational savings. Since they moved onto commodity hardware (affordable virtual x86 servers) from expensive hardware, they saved 40% of the computing power and 20% to 50% of the overall cost.
Kevin Webber remarked upon this migration, “Building microservice architecture is really the key to staying in front of the demands of the market. It’s not just a sort of re-platforming for the sake of technology. It’s about the overall market in general, about what users expect and what business expects to stay competitive.”
Amazon Incorporated Two-Pizza Teams
Amazon.com, the phenomenal retail website, was running on a massive architectural monolith until 2001. Rob Bingham, senior AWS product manager shared the story of how Amazon from there migrated to the microservices platform by approaching the DevOps philosophy.
“A lot of startups and enterprise projects start out this way (Amazon’s was a multiple tiered, and each had many components in them that were coupled together very tightly) They take a monolith first approach, because it’s very quick, but over time, as that project matures and has more developers on it, as it grows and the codebase gets larger, and the architecture gets more complex, that monolith is going to add overhead to your process, and the software development lifecycle is going to slow down.” – Rob
The development team faced many challenges due to the monolith architecture, including:
- Large number of developers working aimlessly on one big monolith website
- Continuous need to deal with coordinating changes with overheads that were also on the same project.
- They had to make sure any new change (bug fixes or new feature addition) did not affect something else on the big project.
- Convince everyone else on the big project to upgrade at the same time, if one particular team wanted to update a shared library.
- Coordinating even small issues like quick fixing a customer issue needed a massive wait period for processes needed to be changed and circulated.
All of these led to something called Merge Week or Merge Friday. However, this large merged version also did not solve the problem and it still added a lot of overhead to the delivery pipeline. Building new code databases, rerunning test cases, and deploying the whole application to full production fleet was crazy and frustrating for software engineers. And we are talking Amazon here, the world’s largest online retail platform.
So, Amazon decided to go for the BIG Organizational and Architectural Change – They teased their monolithic application apart and made it into Service Oriented Architecture. They created highly decoupled architecture, where each service could iterate independently without the need for coordination between those services as long as they followed the standard web service interface.
They also implemented changes in their organizational structure and operations and broke down their central, hierarchical product development team into small ‘Two-Pizza teams’ – teams that were small enough to feed two pizzas.
“We went through the code and pulled out functional units that served a single purpose and wrapped those with a web service interface. We then established a rule, that from now on, they can only talk to each other through their web service APIs.
Back then it didn’t have a name, but now we call it as a microservice architecture.” – Rob
Each of these teams was given new powers and controls, such as:
- Full ownership of one to four microservices, including customer control, defining their own feature roadmap, designing features, and implementing, testing, deploying and operating the new features.
- If anything went wrong in a particular service lifecycle, the two-pizza team appointed for that microservice has to take full accountability to fix it and change it, even if it was in the middle of the night.
- Since organizational teams were properly aligned, engineering teams were energized and motivated to make sure their end-to-end cycle worked properly.
After building microservices architecture, Amazon experienced the following changes:
- Dramatic improvement in the front-end development lifecycle.
- Decision making improved by 100%.
- New features were launched perfectly and quickly.
- Zero coordination issues.
- Now the company makes 50 million developments a year.
Spotify Reached Flawless User Experience
Spotify serves 75 million users per month. An average session lasts 23 minutes. Spotify runs extremely complicated business roles behind the scene. Their competitors are Apple and Google.
A global enterprise, such as Spotify, that has an unparalleled brand name and two most inventive competitors, must move fast and innovate constantly. And this requires a highly scalable and stable architecture, remembers the VP Engineering at Spotify, Kevin Goldsmith.
“If you’re worried about scaling to hundreds of millions of users, you build your system in a way that you scale components independently. The problem is, if you want to build a new feature in this kind of (monolithic) world, then the client team have to ask the core team: please get us an API and let us do this. The core team asks the server team: please implement this on the server side so we can do whatever we need to do. And after that, the server team has to ask the infrastructure team for a new database. It is a lot of asking.” – Kevin Goldsmith.
Since Spotify has 90 teams, 600 software engineers, and 5 development offices operating in two continents working on the same product, they built an autonomous microservices architecture with full-stack teams to minimize the level of dependencies.
Now each of their microservices with full-stack teams consists of its own back-end developers, front-end developers, UI designers, testers, and product owners. Since the teams are autonomous, their goals and mission do not interfere or overlap with other teams’ objectives.
Although the company faces a couple of challenges with microservices, such as difficulty in monitoring thousands of instances running simultaneously and increased latency, microservices architecture have clear advantages for enterprises which Spotify have fully experienced:
- Bottlenecks can be easily identified, tracked, removed or fixed within a microservice, which is complicated in huge monolith applications.
- Testing a smaller surface is easier. Developers can test services locally without having to deploy them to a test environment.
- Since applications are smaller, they deploy quickly and easily.
- Monitoring services is easy in most instances, especially when rectifying a bottleneck.
- In order to stop the addition of multiple versions to the same binary, the need to add support for multiple versions in the same instances is removed. Therefore, versioning can be done independently.
- Microservices will never experience large failures, for their failures will be as small and easily manageable as they are.
Spotify has built its microservices architecture system with the thought that their services can fail all the time. Therefore, building microservices architecture has allowed the enterprise to face downtime of a large number of services without the users even realizing it.
In the end, this is what Kevin Goldsmith had to say about embracing microservices for business value development – “We’ve been doing microservices at Spotify for years. We do it on a pretty large scale. We do it with thousands and thousands of running instances. We have been incredibly happy with it because we have scaled stuff up. We can rewrite our services at will – which we do, rather than continue to refactor them or to add more and more technical data over time. We just rewrite them when we get to a scaling inflection point. We do this kind of stuff all the time because it’s really easy with this kind of architecture, and it’s working incredibly well for us. So if you are trying to convince somebody at your company, point to Spotify, point to Netflix, point to other companies and say: This is really working for them, they’re super happy with it.”
There is no one right way to use microservices architecture for every company. Organizational changes, cultural challenges, process changes, customers, operations, and existing infra need to be considered. Companies need tools to fund the visibility of their microservice infrastructure. The balance of speed and safety at scale is the primary key to understand the value of microservices in business.