Monolith to microservices case study

Monolith to microservices case study

Nov 06, 15 min read. Wojciech Bulaty. Liam Williams. Daniel Bryant. This is the third article in the Testing Microservices series. At Traffic Parrotwe have recently worked with six companies that represented a broad spectrum of industry domains and of maturity in adopting microservices. These companies have used a combination of the testing techniques that we described in Part 1 and assessed in Part 2 of this article series, techniques that allow you to manage dependent components while testing microservices.

In Part 3, we will present case studies that demonstrate how six different companies used these techniques. We begin with three case studies where a combination of testing techniques were applied as a holistic solution. The last three case studies describe the application of a single technique to solve a specific problem.

Monolith to microservices case study proves maintainability matters

LaunchDarkly Feature Management Platform. Dynamically control the availability of application features to your users. Start Free Trial. Priority : Deliver fast; will refactor the release process after the first production release. The startup had two teams working on a set of three new microservices that had to be delivered in two months.

monolith to microservices case study

The microservices were replacing part of a deprecated monolith. The teams decided to test the Go microservices internal components with unit tests using in-process mocks implemented with the GoMock framework. They tested interactions with the database with component-level integration tests, which use a test container database to avoid having a dependency on a shared instance of a database. They also used a handful of manual E2E tests in a pre-production environment to make sure that the microservices would work together in the absence of sufficient automated testing.

They would fill the gaps in automated testing after the first deadline. Since this was a greenfield project that had to go to production on time, the company decided not to version the microservice APIs. Instead, they released everything together to production per release often called snapshot releases.

They allowed for downtime of services and corresponding graceful degradation of the customer-facing components, which was communicated to the customers beforehand. They started to semantically version APIs after releasing the first product.

This allowed them to improve the API change management to allow backwards compatibility and improve uptime for customers. Another interesting issue they came across early on was that the API mocks were becoming obsolete on a daily basis, because the APIs genuinely were changing daily.

These changes were often not backwards compatible, as the developers were refactoring the protocol files to reflect the rapidly evolving domain modelwhich they had not yet clearly defined.

This is a common characteristic of greenfield projects delivered by teams that use an iterative approach to delivering value to customers.

Graphql elasticsearch integration

To hit their deadlines, the company decided to test the API mocks by firing a request at both a mock and a real microservice. This way, the API mocks and the real service were proven to be up to date when compared to the latest definition of the expected behavior defined in the contract file. Priority : Move to API-first approach to allow parallel work and decouple teams.

monolith to microservices case study

Scale adoption of microservices across 3, company developers. The company decided to move away from a monolithic architecture to more autonomous teams and microservices. As part of that transition, they decided to embed recommended good practices rather than force use of specific technologies and solutions onto teams. The architects were responsible for gathering techniques, guidelines, and tools to be used by the developers. They were also responsible for creating an architecture that would minimize waste by reuse of proven techniques, tools, and components.

That way, the BDD tests verify both microservice API request and response and all communication with dependent components by assertions and verifications. The company used JMeter to create performance tests.

JMeter tests test individual microservices, and replaces the dependent components with API mocks of real dependencies like the microservices and the old legacy monolith.

One of the techniques used is configuring response times on the API mocks and observing the impact of increased latency on the calling service.A large, consumer-facing IoT device network that relied upon a monolithic architecture found that the network struggled to keep pace with increasing demand. In response, the team built a lightweight microservices system using the Micronaut framework, which provided the smooth learning curve, extensibility, speed, testing ease, and scalability necessary to better serve its growing customer base.

SmartThings, a subsidiary of Samsung Electronics, provides consumers at-home IoT experiences through a range of sensors, smart devices, and digital apps. SmartThings customers have the ability to control, automate, and monitor household fixtures, such as lights, locks and security systems, electrical outlets, and more, via their mobile devices.

Homeowners who invest in smart technology expect immediate and consistent responses to both scheduled and spontaneous commands. SmartThings' existing monolith application controlled approximately services from a central server.

Get ip telegram bot

The compute power necessary to manage this load was not only unwieldy, it resulted in unacceptable startup times during peak usage. Additionally, extensive manual testing was required for each software change, and a single update test could take between 45 to 90 minutes for each service.

This made continuous deployment difficult and resulted in taxing development cycles. Finally, the company's growth exhausted compute resources and ability to scale; the more commands executed by SmartThings users, the greater the stress on the application.

To further complicate matters, unpredictable surges in user behavior caused periods of reduced performance. First, the SmartThings Hub and its mobile app required a new infrastructure that would allow for performance of critical operations at sub-second speeds.

To deliver the speed and scale expected by its customer base, SmartThings set a millisecond max on response time. This time limit represents the threshold of human perception, meaning any span of time longer than milliseconds is likely to be noticeable as a "delay" to the user. Next, any new feature implemented needed to be extensible into the distant future, and the company's engineers sought to reduce as much boilerplate as possible to accelerate development cycles.

Thus, only solutions that empowered the SmartThings engineering team to rapidly develop, test, and release new software features were considered. Finally, the new system had to be scalable to both accommodate the growing number of potential users and to address load during peak use times. SmartThings recognized that it needed to transition away from its legacy monolith architecture to a more flexible microservice-based system. A microservice architecture allows for nimble development and delivery of a wide range of interoperable services that may be modified and deployed independently.

Such a solution clearly offered significant benefits to both the internal development team and the company's client base. Once SmartThings leaders decided to transition their massive and complex existing system to a lightweight, interconnected infrastructure, they faced the challenge of building and migrating to their new platform as efficiently as possible. Micronaut may be used in scenarios that would not be feasible with traditional MVC frameworks, including Android applications, serverless functions, IoT deployments, and CLI applications.The following shows a case study about successfully moving from a very complex monolith system to a cloud-native architecture.

The architecture leverages containers and Microservices. This solve issues such as high efforts for extending the system, and a very slow deployment process. The old system included a few huge Java applications and a complex integration middleware deployment.

The new architecture allows flexible development, deployment and operations of business and integration services. Besides, it is vendor-agnostic so that you can leverage on-premise hardware, different public cloud infrastructures, and cloud-native PaaS platforms. The session will describe the challenges of the existing monolith system, the step-by-step procedure to move to the new cloud-native Microservices architecture. It also explains why containers such as Docker play a key role in this scenario.

A live demo shows how container solutions such as Docker, PaaS cloud platforms such as CloudFoundry, cluster managers such as Kubernetes or Mesos, and different programming languages are used to implement, deploy and scale cloud-native Microservices in a vendor-agnostic way.

Here are the slides and video recording. Your email address will not be published. Save my name, email, and website in this browser for the next time I comment. By Kai Waehner February Total. Share 0 people shared the story. Key Takeaways Key takeaways for the audience: — Best practices for moving to a cloud-native architecture — How to leverage microservices and containers for flexible development, deployment and operations — How to solve challenges in real world projects — Understand key technologies, which are recommended — How to stay vendor-agnostic — See a live demo of how cloud-native applications respectively services differ from monolith applications regarding development and runtime Slides and Video from Microservices Meetup Mumbai Here are the slides and video recording.

Like 0. Tweet 0. Pin it 0. Kai Waehner builds mission-critical, scalable, streaming infrastructures with Apache Kafka. Leave a Reply Cancel reply Your email address will not be published. You May Also Like.

Read More. One of the first questions is: Which technologies and frameworks shall we use? The backend will be Java or another modern JVM language, as we are mainly experienced Java developer. In most use cases, we also prefer web frameworks, which allow to code mostly in Java, as many of us just have basic knowledge regarding HTML and JavaScript. We took a look at pros and cons, which are listed below in this blog post. Read More views 8 minute read. Read More views 3 minute read.

Read More 2.Most monolith to microservices examples start off with developers yearning for more application stability during frequent code updates, or the ability to scale without resource compromises, or a route out of dependency hell. But Scott Bassin, engineering director at Ibotta Inc. New developers struggled to comprehend a whole application to develop features or improvements for it. With microservicesengineers can focus on one independent functional component of the application: "[Microservices] future-proof the app for the skilled workforce," he said.

Oscp salary quora

See how this monolith to microservices case study worked out for Ibotta, and what lessons other application developers and digitally focused companies can learn from their migration. Microservices are generally language-independent, so an organization can stick with whatever modern code language the staff already uses, such as Java or Python.

Developers must adjust their perspective on application architecture to make the migration to microservices.

Unlock accde

Developers in independent teams can work concurrently on an application with a microservices architecture, but they must understand the context of their project within the broad architecture.

Microservices are grouped by business domains for the core values they provide, Bloomberg explained.

Migrating a Monolithic Application to Microservices (Cloud Next '19)

Microservices that share a business domain are tightly coupled to provide related tasks and functionality within applications. To compose an application, these domains form loosely coupled relationships. Organizations considering a migration to microservices should model the existing application architecture to this domain-based setup.

A decoupled, business-driven microservices architecture lets engineers know exactly what problem to focus on, Bassin said.

Monolith to Microservices: Migrating Snap’s Architecture Using a Service Mesh

He added that the microservices architecture drives development in his team at Ibotta to a degree he didn't anticipate when the migration began. Microservices push what he calls slowness factors, such as scaling limitations and dependencies, out of application features. Organizations that move from monolith to microservices address technical debt, especially in large enterprises, said Brandon Carroll, director of transformation, DevOps and cloud services at IT services provider TEKsystems Inc.

Developers aren't required to manage code in place with microservices as they do with monolithic apps. They can quickly release code to a container rather than deploy a whole app update. Enterprises can reduce total cycle times and deploy releases faster with independent microservices because they no longer manage thousands of lines of dependent code.

Ibotta's team turned to microservices development with the addition of its 30 th engineer, but Bassin said if he could go back to day one, he would have started the migration to microservices sooner. He advises other software teams look at Ibotta as a case study and lift core functionality out of a monolithic application more proactively than his team did. Ibotta's developers still work with a monolith in tandem with microservices, and that's not an unusual scenario, Bloomberg said.

Microservices solve some problems with additional flexibility and new business capabilities, even when the big, old software architecture refuses to die.

Modularized applications are patterns that date back to the advent of object-oriented programming and then service-oriented architecturebut there's no magic formula. Microservices are a technological change driven by people, the Ibotta monolith to microservices case study shows. Hiring managers should seek team members that advance the organization's digital roadmap -- you don't pick up microservices developers to maintain the status quo, Bloomberg said. Carroll exhorted company leaders to engage with this effort.

Hire great talentbut don't stop there. Shepherd existing staff through the cultural and skills changes to work with microservices, and invest in tooling to create and support modern apps.Well, if you look at the growth of companies using microservices, the answer is absolutely yes. The microservices architecture market is growing at a steady pace. Given this trend, let's take a closer look at the advantages and disadvantages of adopting microservices.

The growth is fueled by companies who are frustrated by their IT departments moving slowly and are looking to move to modern application development practices focused on speed and agility. Basically, the cloud has made it easier to split a monolith application into manageable microservices.

Much of this growth has also been stimulated by cloud-based solutions that make it easier to create microservices. More on that later. A microservices architecture is an approach to developing an architecture that emphasizes modularity and independence of each application. Instead of building a single monolithic applicationmicroservices split an application into discrete sets of smaller, interconnected services that each have their own business logic, database, and other adapters connected by APIs to other services.

This approach has been trending since and has become especially popular in connection with the adoption of more Agile and DevOps frameworks for enterprise software development. In plain English, a microservices architecture allows you to develop and publish an application without breaking another, which is a significant problem in monolith applications. The term "microservices" was first used in at an event for software architects, where it described a style of architecture many attendees were experimenting with at the time.

Netflix and Amazon were among the early pioneers of microservices. As with anything, microservices are great for certain use cases and bad for others. A microservices architecture should be implemented when:. Netflix, for example, which pioneered microservices at scale, estimates it uses close to microservices to control the many parts that comprise its service.

Zamtel management

AWS is how. These services encompass everything from computing and storage, databases, analytics, recommendation engines, video transcoding, and involve overserver instances on AWS. There are a lot of great things to say about microservices.

As I just mentioned, some of the best, growing technology companies use microservices-based architectures. So, before you begin your journey with microservices, please know that implementing microservices can become complex very quickly. There are many resources on the web to help you get started.

That should give you enough homework to start with, but let us know if you have questions. Within a microservices architectureeach service manages its own data to avoid conflicts and dependencies in case one system fails.

For example, an application that manages a collection of car parts will require a number of services—including what happens when a new delivery is scheduled, pickup and drop-off locations, and size and weight of the package. All of these services require different read and write profiles. Since each service has its own data storage requirements, the type of storage will differ.Challenge Moving from a monolith to microservices in "solved a problem on the development side, but it pushed that problem to the infrastructure team," says Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace.

Before, their VM deployment would take half an hour; now, says Lynch, "someone can generate a templated application, deploy it within five minutes, and have actual instances containerized, running in our staging environment at that point.

Today there are twice that in the pipeline being actively worked on. Since it was started in a dorm room inSquarespace has made it simple for millions of people to create their own websites. Microservices solved a problem on the development side, but it pushed that problem to the Infrastructure team.

The infrastructure deployment process on our 5, VM hosts was slowing everyone down. We use Calico for CNI networking for Kubernetesso we can announce all these individual Kubernetes pod IP addresses and have them integrate seamlessly with our other services that are still provisioned in the VMs.

After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid and found that it "answered all the questions that we had. Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. He adds: "When we started the Kubernetes project, we had probably a dozen microservices.

It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And it worked out of the box.

Tacoma lokka

Kubernetes has been really great for trying something out quickly and seeing if it works or not. The first tool injects dependent applications as containers in a pod. Going forward, all new services at Squarespace are going into Kubernetes, and the end goal is to convert everything it can.

About a quarter of existing services have been migrated. Someone just did it and it worked—painlessly. Maybe I should just take my own advice and fail fast!Apr 17, 3 min read. A Kulkrani. Service oriented architecture enabled scalability and ownership for engineers. Open source edge proxy Envoy is the core building block, creating a consistent layer for inter-service communication.

The cloud infrastructure evolved in the past two years from running a monolith in Google App Engine to microservices in Kubernetes across Amazon Web Services and Google Cloud. Some of the challenges for starting with a microservice-based system from scratch included consideration towards their existing underlying infrastructure such as network topology, authentication, cloud resource provisioning, deployment, logging and monitoring, traffic routing, rate limiting, and staging and production environments.

As detailed on Snap Engineering blog, in order to find a feasible plan, they considered the current experience of Snapchatters as well. It was also stated that there was no team of dedicated engineers and hence there was no time to implement this plan. Instead of starting from scratch, Snap decided to go ahead with the service mesh design pattern with open-source edge proxy service Envoy.

At Snap, each Envoy proxy connects a custom control plane, receiving service discovery and detailed traffic management settings over its xDS API. With service mesh, it was important to address questions around the mobile client communication scheme in Envoy. Along with that, when working across AWS and Google Cloud, engineers had queries around managing their Envoy configurations from a security standpoint.

From that, Snap Service Mesh was formed. Snap Service Mesh has an internal web app, named Switchboard, which is a single control panel for Snap's services so that service owners can manage their service dependencies. The Switchboard configuration has services at its core. Each service has a protocol and basic metadata - owner, email list and description.

The clusters with these services can be in any cloud provider, region or environment.

monolith to microservices case study

Switchboard services have their dependencies and consumers, which are other Switchboard services. If Snap were to expose the entire system API interface to their engineering teams, there would have been numerous configurations, resulting in difficulty in managing them.

Configuration changes in Switchboard are saved in DynamoDB. When the Envoy configuration is generated for a service, the control plane sends the updated config to a small subset of Envoy proxies and measures their health before committing the changes across the mesh. Along with this, service owners can provision and manage Kubernetes clusters directly from Switchboard.

They can also generate spinnaker pipelines with canaries, healthcheck endpoints and zonal rollouts. In the interest of keeping a minimum number of services exposed to the internet, Snap has designed a shared, internal, regional network for their microservices.

monolith to microservices case study

An API gateway will be exposed to the internet, so that no external traffic source can communicate directly with the internal network. This API gateway runs the same Envoy image that the microservices run, connecting to the same control plane. There are custom Envoy-Filters which handle Snapchat's authentication schemes along with rate limiting and load shedding.

Improve the reliability of your applications, prevent outages, and reduce downtime with Gremlin's enterprise Chaos Engineering service. Get a demo. Join a community of oversenior developers.

From monolith to microservices: Horror stories and best practices

View an example. You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered. Is your profile up-to-date? Please take a moment to review and update. Like Print Bookmarks. Apr 17, 3 min read by A Kulkrani. Author Contacted. This content is in the DevOps topic. Related Editorial.


thoughts on “Monolith to microservices case study

Leave a Reply

Your email address will not be published. Required fields are marked *