Building Modern Applications with Microservices: Part 1

Jason Ma
May 6, 2016 | Updated: January 20, 2017
#Technical

This is the first in a two post series about microservices. This post discusses the background behind microservices, new technologies that have enabled them, and the benefit of microservices.

Introduction

As enterprises work to replicate the development agility of internet companies and innovate in highly competitive markets, application development has grown increasingly complex. The large, monolithic codebases that traditionally power enterprise applications make it difficult to quickly launch new services. Siloed and potentially distributed development and operations teams present organizational alignment problems. On top of this, users are more demanding than ever – enterprises need to scale effectively and monitor deployments to ensure customers are provided with high performance and a consistent experience. Of course, all this needs to be done while providing always-on service availability.

Due to these trends, there is demand for a software architecture pattern that can handle the requirements of the modern age. Monolithic architectures have been the traditional approach, but limitations with scaling, difficulties in maintaining a large codebase, high risk upgrades, and large upfront setup costs have compelled enterprises to explore different approaches.

In the last few years, microservices have come to the forefront of the conversation. They have been rapidly adopted, due to their ability to provide modularity, scalability, high availability, as well as facilitate organizational alignment.

The Monolith

Before microservices, a common approach to application design was to use a monolithic architecture. In this mode of development, the application is developed, tested, packaged, and deployed as a single unit. Codebases are compiled together, and the application is deployed as one entity. Scaling required copying instances of the application binaries and the required libraries to different servers, and the application code typically ran as a single process. Continuous delivery — an approach that involves fast, iterative software development and safe updates to the deployed application — was challenging since the full monolithic application stack needed to be recompiled, relinked, and tested for even the smallest incremental release.

What are Microservices?

Microservices is a software architecture where applications are broken down into small autonomous services. Services are typically focused on a specific, discrete objective or function and decoupled along business boundaries. Separating services by business boundaries allows teams to focus on the right goals and also ensures autonomy between services. Each service is developed, tested, and deployed independently, and services are usually separated as independent processes that communicate over a network via agreed APIs, although in some cases that network may be local to the machine.

Microservices grew from Service Oriented Architecture (SOA), which gained popularity in the early 2000s and emerged as a way to combat large monolithic applications. Key differences between SOA and microservices are:

SOAs are stateful, while microservices are stateless
SOAs tend to use a enterprise service bus for communication, while microservices use a less elaborate and simple messaging system
SOAs may have hundreds or thousands of lines of code, while microservices could have less than one hundred lines
SOAs put a greater emphasis on reusability (i.e. runtime code, databases), whereas microservices focus on decoupling as much as possible
A systematic change in a SOA requires modifying the monolith, whereas a systematic change in a microservice is to create a new service
SOAs use traditional relational databases more often, while microservices gravitate more towards modern, non-relational databases. Further sections will cover the advantages of non-relational databases over relational databases in a microservices architecture

Many architects found that SOAs suffered problems with communication protocols and lacked sufficient guidelines on effectively separating services, which laid the foundation for microservices to emerge as a best practice method to implement a truly SOA.

New Technologies Enable Microservices

The downsides of deploying and provisioning hundreds and potentially thousands of services did not outweigh the benefits gained with a microservices architecture (faster development, scalability).

The emergence of technologies such as containers (Docker, LXC) and orchestration frameworks (Kubernetes, Mesos) mitigate many of the problems that prevented using microservices architectures in the past.

Containers are lightweight run-time environments that provide isolation and scalability with minimal impact to performance and capacity. Packaging is simplified as the same environment can simultaneously host development, support, test, and production versions of the application, so that going from dev to test to QA to production is easier. Containers work very well in a microservices environment as they isolate services to an individual container. Updating a service becomes a simple process to automate and manage, and changing one service will not impact other services, provided that APIs are maintained.

Figure 1: Container in microservices

When organizations start running containers at scale, many look to orchestration frameworks to help manage the increased complexity. Orchestration frameworks help deploy and manage containers: provision hosts, instantiate containers, handle failures, and provide automated scaling. Kubernetes and Mesos are popular orchestration frameworks that make it easier to deploy containers at massive scale in a microservice environment.

To learn more about building microservices architectures with containers and MongoDB, download our guide: Enabling Microservices: Containers and Orchestration Explained

Benefits of Microservices

Many organizations can better meet the needs of modern application development by implementing microservices. The benefits include:

Faster Time To Market: In a monolithic application, any small change in the application will require redeploying the entire application stack, which carries higher risk and complexity. This results in longer release cycles, as changes may be batched together and not released until reaching a minimum threshold. With microservices, a small change to a service can be committed, tested, and deployed immediately since changes are isolated from the rest of the system.

Continuous integration — a software practice of integrating and testing developer changes to the main code branch multiple times a day — is much simpler and faster as there are fewer functions to test. This results in a more iterative release cadence as less code needs to be compiled and retested. Orchestration tools such as Kubernetes facilitate faster time to market by automating the on-line, rolling upgrade of containers, and providing the ability to roll back any changes should they be necessary.

Flexibility and Scalability: Monolithic applications require all components of the system to scale together. If one service requires extra performance, the only option is to scale all the services rather than the individual service that needs additional capacity. With microservices, only the services that require extra performance need to be scaled. Scaling is achieved by deploying more containers, enabling more effective capacity planning, less software licensing costs, and lower TCO as the service and hardware can be matched more appropriately.

Figure 2: Scaling containers

Resiliency: A major issue with monolithic applications is that if a service fails, the whole application may be compromised. In microservices, service boundaries serve as natural isolation barriers to prevent cascading failures from bringing down the whole system. If using containers, orchestration frameworks can provide added resiliency: when one container fails, a new one is started, restoring full redundancy and capacity.

Alignment With Organization: Microservices enable better alignment of the architecture to the organization, as team sizes can be optimally defined to match the required tasks. Teams can be broken down into smaller groups and focus on a single component of the application. This is especially useful for distributed teams. For example, if a team in Singapore handles three services, while a team in San Francisco handles five services, each team can release and deploy features and functionalities independently. This helps break down silos between teams and fosters better collab oration as cross discipline teams (Ops, Dev, QA) collectively own the services. This also ensures that the communication between teams matches the communication through the services' APIs. Essentially, the APIs between services define a contract between development teams on what each service should provide to others.

Reduction in Cost: By using containers, applications and environments (design, test, production, support) can better share the same infrastructure, resulting in increased hardware utilization and reduced costs due to administrative simplification. In addition, microservices also help reduce technical debt. With a monolithic application, there are costs (time, resources) associated with refactoring code for a large application. By breaking the application into API accessible microservices, code refactoring can be done service by service, resulting in less time maintaining and updating code.

In the second part of this blog post series, we will discuss how MongoDB enables microservices.

Learn more about MongoDB and microservices. Read the white paper.

Microservices: The Evolution of Building Modern Applications

About the Author - Jason Ma

Jason is a Principal Product Marketing Manager based in Palo Alto, and has extensive experience in technology hardware and software. He previously worked for SanDisk in Corporate Strategy doing M&A and investments, and as a Product Manager on the Infiniflash All-Flash JBOF. Before SanDisk, he worked as a HW engineer at Intel and Boeing. Jason has a BSEE from UC San Diego, MSEE from the University of Southern California, and an MBA from UC Berkeley.

← Previous

One Domain for GIANT Ideas: An Update to MongoDB Web Properties for an Improved User Experience

Today we are consolidating our two main web domains - mongodb.com and mongodb.org - into a single domain in order to enhance our user experience. Our two domains serve millions of unique visitors per month. However, we found having two domains created a counter-intuitive user experience for visitors. Community members and customers often ask why we had two domains for the same company and solutions. Users who naturally came to one site would be unaware that the other existed. In addition, our rich content, which lived across domains, often ended up competing in SEO, making it difficult for our visitors to find what they were looking for. As we added new web properties, like Cloud Manager, WiredTiger and MongoDB University, it became more challenging for us to create an integrated experience for our visitors and customers across the two domains. Merging the domains is a natural evolution. We think this change will create a more intuitive navigation and browsing experience for our community and our customers. We hope to solidify a consistent introduction to MongoDB for all visitors, whether they are a developer looking to download for the first time, a database admin looking to maintain their mission critical app in production, or a CIO looking to innovate and cut costs by researching database solutions. By simplifying the discovery of content for those browsing the site, we think our users will accelerate their ideas and companies. MongoDB.com will be the launchpad for GIANT ideas. We believe this new approach provides a more modern, consistent and intuitive web experience. If you have feedback on our website, please feel free to post in the comments of this blog. About the Author - Meagen Eisenberg Meagen Eisenberg is CMO of MongoDB. She brings more than 20 years of experience in the high-tech industry to her role at MongoDB. She has been recognized as one of the Top 50 most retweeted by mid-sized marketers according to AdWeek and one of the Top 25 B2B Marketing Influencers according to InsideView. In 2014, she won the Marketers that Matter award. Additionally, she won the SuperNova Award in Matrix Commerce from Constellation Research in 2012 and the Marketing Visionary Markie award within the marketing automation field in 2011. Meagen advises for several tech startups and before joining MongoDB, she was the Vice President of Customer Marketing and Demand Generation at DocuSign. She also held previous positions with ArcSight, an HP Company, TRIRIGA (acquired by IBM), Postini (acquired by Google) and IBM. Meagen has an MBA with a focus on marketing and strategy from Yale School of Management and holds a B.S. in MIS with a minor in CSC from California Polytechnic University at San Luis Obispo.

May 5, 2016

Next →

Women Leaders at MongoDB: Lena Smart Discusses Clarity and Goal Setting

March is Women’s History Month. Our women leaders series highlights MongoDB women who are leading teams and empowering others to own their career development and build together. Lena Smart, Chief Information Security Officer, explains why words matter, shares her thoughts on leadership, and discusses MongoDB’s internal mentorship program “MentorHER”. Tell me a bit about your team. My team is responsible for all aspects of security of MongoDB’s global offices and employees. Within my organization I have Governance, Risk and Compliance (GRC) and InfoSec (security engineering, physical security, etc.) under me. We are dedicated to making every effort to protect customer data, including continually improving security processes and controls. On top of that, we are committed to delivering the highest levels of standards conformance and regulatory compliance as part of our ongoing mission to address the most demanding security and privacy requirements of our customers. My goal is to build the best security and GRC team in the world. What characteristics make a good leader? In my opinion, good leaders are decisive and leave little room for ambiguity. They are understanding and know that people are depending on them for their careers, dreams, and aspirations. They make their work matter every day, are focused on continuous learning, and do not “rest on their laurels.” What has your experience been like as a woman growing your career in leadership? My experience as a woman leader has depended on the environment. It was very difficult as a CIO and CISO in the power industry. Every day I felt like I was being undermined by my peers, who (because they were all “power industry engineers”) felt they were the experts in everything to do with security (they were not). It was exhausting. I finally left and joined a FinTech company. That was better, but I still felt I could find an environment where women were actively encouraged to lead. Hence my move to MongoDB. I could not be happier here and love working with all our teams. Tell us about the biggest lesson you’ve learned throughout your career. The biggest lesson I’ve learned is that words matter. As a leader, people can interpret your words in many ways. Be clear in your message. I have a mantra on our team: “one voice, one message”. I encourage my team members to have all the internal discussion they want, but we do not ever air our dirty laundry in public. We stand with “one voice, one message”. People in general like clarity, and we try hard to enforce that idea within my team by encouraging each person to own what they do. What’s your advice for building and developing a team? I believe cultivating a supportive and positive team culture stems from the top down. I really embrace and follow MongoDB’s company values . Build Together is the main value I follow because, to me, people are everything. You need the right people in the right places owning what they do. I am also a huge advocate for people taking the initiative and building upon their own careers. I make sure to set aside a budget for training and certification programs for my team. This allows them to enhance their knowledge and helps them grow and develop into even stronger security and GRC professionals. I also started the Security Champions Program at MongoDB almost four years ago, a volunteer-based program that allows anyone who has an interest in security to join monthly meetings to learn more. Can you tell us a bit about the MentorHER program at MongoDB? I am honored to be the Executive Sponsor for a very important internal program called MentorHER. MentorHER aims to create diverse teams, develop female leaders, drive organizational changes, and enhance MongoDB’s reputation as an employer of choice. I’ve had a couple of mentors who made a positive impact on my career. I cherished our time together and made sure to have a clear understanding of the mentoring program I signed up for. There were goals, regular meetings, and a lot of positivity generated by mentoring. I hope we can replicate that at MongoDB with our MentorHER program. We have a very strong team leading the program, and I feel very confident that we will meet our goals and embrace the different experiences and perspectives of the women around us. What is your advice to women looking to grow their careers as leaders? My advice to other women is this: be clear and honest in what you want from a leadership role. At the C-suite level you will be pulled in many directions. Control that, from the start, where possible. It’s important to be intellectually honest and have clear goals that will help your team grow and mature, and the business flourish. Join a team that builds together every day. View open career opportunities at MongoDB.

March 27, 2023