Microservices vs. Monoliths

Microservices vs. Monoliths

Armedia Solution Engineering Team

  • Vishal Deshpande
  • Andrew Slade
  • William Phillips
  • Naga Krishna Sumanth Kovvuri

When Should I Use Microservices?

Microservices are a powerful and useful tool when used appropriately. However, they are not a magic bullet to solve all software design woes in comparison to monolithic architectural design. Like most issues, there are great benefits and serious downsides to both microservices and monolithic applications. It is imperative to review your use case carefully and determine which course is the best for your application.

What Are The Benefits Of Using Microservices?

There are a few big benefits to using microservices in comparison to monolithic applications.

Microservices are inherently separated from one another, which promotes a better focus on the scope as well as keeping code succinct which eases future maintenance. These services can be specially designed to accomplish one task very well, and changes to update or improve a service will not break interactions with other microservice so long as the existing API works as expected.

Unrelated services do not impact one another. For example, in a monolith application you have Service A and Service B. Now, let us say that Service B malfunctions and crashes. Because they are part of the same system, Service A will be brought down as well. However, with microservices, because services are separated from one another, Service A will not be impacted if Service B crashes. In addition, deployments of a service can happen while all other services are still live.

Another benefit is improved scalability. If only a few services are being hammered enough to require scaling, you only need to scale those services. In a monolith, you would have no choice but to use additional resources to scale all the other services, which would lead to wasting resources. This is especially useful in cloud-based hosting because careful control of resource use is more cost-effective.

Finally, you are able to use whichever language or software stack for your microservice as needed, so long as it can meet the requirements of your architecture. This can enable teams to explore new technologies and features without having to re-write an entire monolith. In fact, some languages have better developed open-source libraries for certain tasks, such as image processing or voice recognition.

What Are The Downsides Of Using Microservices?

Microservices don’t come without drawbacks, however.

The single biggest issue is the increased complexity of handling the microservice architecture. The system is a distributed application, so there will need to be additional work towards the discovery and coordination of each microservice. Because of this complexity, you will need to design your application more up front in comparison to a monolith.

There are additional headaches when it comes to synchronizing services and keeping your data consistent between microservices. When it comes to communication between microservices, you have no choice but to use remote calls, which have slower performance and the calls may get lost, delayed, or even fail. In addition, trying to keep calls transactional can be a nightmare when a transaction goes between multiple microservices.

Testing is also difficult with microservices. In order to test full functionality, you either need all dependent microservices running or you need appropriate mocking of values to simulate the environment.

In Summation

As stated earlier, there is no right or wrong answer. The common sense approach is if your application is small, won’t need to scale up very far, and you want it to be simple to deploy, a monolith is a right answer. A microservice solution for that problem would add too many layers of complexity to the benefits.

However, if your application will be very large, will constantly be expanding on features and offerings, and want extremely strong and fault-resistant system, then microservices may be the better solution.

Introduction To Microservices

Introduction To Microservices

introduction to microservices

Armedia Solution Engineering Team

  • Vishal Deshpande
  • Andrew Slade
  • William Phillips
  • Naga Krishna Sumanth Kovvuri

What Are Microservices?

The microservice architectural design is a style of software architecture design which allows for increased encapsulation and separation of functionality. It is utilized successfully by large companies such as Netflix, Amazon, Uber, eBay, and many more.

Microservices are tiny, focused, optimized services that meet a specific goal with a very limited scope. They produce reusable building blocks which aid both developers and clients. In addition, microservices allow greater resiliency and reliability because if a lone microservice fails, this failure does not have to bring down the entire application.

Another benefit of microservices is that they can be re-used multiple times by separate microservices or applications, which saves development time and increases the value of your existing code.

What Is The Microservice Architecture?

The microservice architecture is the organization, management, and access to a collection of microservices. It utilizes an intermediary to facilitate communication between different microservices, as well as between microservices and the outside world. This intermediary also tracks the addition and removal of services, the status of running services, as well as the documentation for each service.

Why Use Microservices?

To understand the appeal of microservices, we must first explain the monolith. A monolith is the “traditional” style: a large application is made up of several services, all working together to achieve a goal. It is deployed on one location, utilizes one set of resources, and deployments, upgrades, and updates usually require the entire system to be shut down.

If two monoliths have a service or component with similar functionality, the code is a duplicate which wastes development time and resources; monoliths essentially reinvent the wheel every time a new application is needed.

Conversely, a set of microservices attempts to separate and de-couple each service as best as possible. Each microservice has its own container and can be co-located on the same server as other microservices or each microservice can be siloed on its own server.

Microservices can talk to each other and work in tandem to solve needs, and a single microservice can be used as a dependency for countless other microservices. This means if two separate clients have an overlapping need, a single microservice can be used for both clients.

What Are The Benefits Of This Approach?

Microservices are very effective in that each microservice can have its own allocated resources. If one microservice is not getting much traffic, its resources can be reduced, and if another microservice is getting hammered with traffic, its resources can be ramped up. This division of resources allows for targeted scaling as necessary and can provide information to usage patterns which may not have been as readily available.

As stated earlier, if a single microservice goes down then your application is not necessarily affected. Only a microservice which is dependent on the downed microservice will be affected, all others will operate normally. In this sense, each microservice is its own fully formed application, but much smaller in scope.

How Do Large Companies Leverage This Style?

Netflix is a company which values uptime as their highest priority. Netflix developed a unique testing tool, “Chaos Monkey,” to vet their system. “Chaos Monkey” is a powerful tool which “randomly disables our production instances to make sure we can survive this common type of failure without any customer impact.” (Yury Izrailevsky, 2011) This tool tests the microservices idea to the highest level by destroying running active services and analyzing the effects of disaster-recovery tools.

Netflix shifted to microservices from their previous monolithic approach because they saw the value of the distribution of services and the resiliency of their architecture when Chaos Monkey is on a rampage. Now when a microservice fails they can take down that specific microservice and either diagnose the issue or spin up another microservice to restore functionality.

What Are The Concerns Of This Approach?

The development of microservices is not without its own concerns. Because the idea of microservices is improved reusability and granularity, each microservice must be designed as cleanly and optimized as possible.

Because each microservice is separated, if a microservice makes a call to a failed microservice, unexpected consequences can occur. An application must be designed to accept and accommodate failure between services. Because of this, it may result in overall larger infrastructure costs and concerns as you will need to be prepared for calls to other services to fail at unexpected times.

Documentation is also extremely important, as each component is potentially a building block in future applications. Therefore, the functionality must be clearly defined and expected. When it comes to designing a microservice, thought should be given for potential future use cases of the service. Due to the complexity of this system, it can result in greater planning complexity.

Are Microservices Worth Utilizing In My Project?

As is usually the case, the answer is not a simple yes or no. Microservices can be more resilient but can fail in unexpected ways if a dependent microservice fails. If this potential failure is not adequately prepared for, such as through effective exception handling, your application can randomly fail at inopportune times.

Since each service is specialized they can be more efficient, but the tradeoff is greater architectural development complexity and design. Each microservice can have exactly the amount of resources it requires, but because it is separated out from other services, it will have a larger overhead cost in comparison to a monolithic application.

In short, there is no right or wrong answer between monoliths and microservice architectures. Each can be correct or incorrect depending on your organization’s and your clients’ needs, expectations, goals, and experience.

Armedia Architecture Example Diagram

Below is an example of how the gateway interacts with each microservice as well as exterior applications. A detailed discussion of each application to be accomplished in a future blog post.

Armedia Architecture Example Diagram

 

Alfresco for Government: Do More with Less

In today’s information-centric age, government organizations face the daunting challenge of offering enhanced services to citizens while simultaneously improving efficiencies and cutting costs.

Let’s face it, whether you’re talking about the Affordable Care Act, the Dodd-Frank Act, changing food and drug safety standards, governing interstate land sales, or a mandate in Massachusetts that requires daycares to brush children’s teeth after lunch (check the reg for yourself), one thing is for sure, massive amounts of information will be generated.

This information will undoubtedly live in millions of documents and records. As always when dealing with the federal government, intense compliance and auditing (both internally and externally) activities need to be incorporated. If that wasn’t enough, recent years have seen a huge push on federal agencies to:

  • Invest in shared services
  • Increase ROI and reduce costs
  • Increase Communications with Citizens
  • Increase inter and intra-agency collaboration

One thing is for sure, you can absolutely expect for the business processes that govern this information to become more complex.

Many business processes will be required to author, review, process, and distribute information.  With compliance and auditing (internal and external) activities in the mix, you can expect an increased need for collaboration and information sharing, and increased reporting requirements – all in the face of enormous growth in content generation and replication.

And although the “Inventor of the Internet” has his own system to manage information, it may not be optimal for anyone collaborating with him.

Al Gore - Inventor of the Internet

Many organizations point to compliance and lack of control as major drivers of adopting an enterprise content management (ECM) solution.  ECM technology has enormous potential to add value by helping government organizations streamline and automate workflow and records management.  ECM is increasingly being used to help manage the lifecycle of unstructured content such as images, documents, reports and web sites, while maintaining the integrity of that content and controlling access to authorized personnel, whether they are located within or outside the organization.

While there are a number of established ECM products in the market, a number of our government customers are asking us to do the same thing that they are being asked: do more with less.

Doing more with less is a pervasive theme throughout the federal government and is quickly being applied to budget-conscious organizations.  As organizations assess resources, functions, and initiatives to support a diminishing budget, information technology spending often becomes the subject of reduction.

This has resulted in a variety of trends across the federal government as CIO’s and CTO’s embark on the challenge of meeting increasing requirements with diminishing funds, such as:

  • Cloud-First Initiative (published February 8, 2011) states that “for the Federal Government, cloud computing holds tremendous potential to deliver public value by increasing operational efficiency and responding faster to constituent needs.” CLICK HERE FOR MORE INFO
  • Shared-First Initiative (published May 2, 2012) requires that agencies use a shared approach to IT service delivery in an effort to increase collaboration and efficiency. CLICK HERE FOR MORE INFO
  • Digital Government Initiative (published May 23, 2012) which requires that “the US Federal government adjusts to this new digital world and seize the opportunity to procure and manage devices, applications, and data in a smart secure and affordable way through the rapid dissemination of lessons learned from early adopters of new technologies.” The initiative goes on to say that agencies should leverage existing services and contacts, build for multiple use cases at once, use common standards and architectures, participate in open source communities, and launch shared government-wide solutions and contract vehicles. CLICK HERE FOR MORE INFO

When asked to meet the challenge of helping our numerous federal clients “Do More With Less,” we always seem to come back around to the platform that can answer each of these challenges:

Alfresco

Alfresco_and_Government

The proven Alfresco open source content platform delivers on all of the objectives of all three of these initiatives. Alfresco is a robust, scalable, and high performance open source Enterprise Content Management platform that is utilized to automate the capture/creation, maintenance and management, and disposal of content.  As the ONLY open source records management platform that is certified to the U.S. Department of Defense (DoD) Joint Interoperability Test Command Product Register DoD 5015.2 STD, the Alfresco solution provides all of the functionality needed to help government organizations capture, classify, control and manage of a wide range of electronic records.

The Alfresco platform also uses flexible, open-standards architecture to provide a full range of information technology services within a single repository, allowing government organizations to apply multiple use cases to their investment. These include:

  • Document Management
  • Web Content Management – through easy integration with existing or new systems, such as Drupal or Crafter Software
  • Records Management
  • Collaboration
  • Federated Search Software
  • Case Management
  • Document/ Records Capture
  • eDiscovery

Armedia’s experience deploying Alfresco solutions has allowed our customers to do more with less by providing:

  • Cost advantage – A low cost, subscription model with minimal upfront investment that can be driven out of operating expense as opposed to capital expense
  • Flexibility – The ability to modify the source code enables agencies to respond more rapidly to changing situations, evolving requirements
  • Greater Customer Choice – Lower Total Cost of Ownership (TCO) by reusing existing hardware, software and skills. No lock-in to one enterprise content management vendor or one stack.

 

Armedia has leveraged Alfresco’s open architecture to integrate it with legacy applications and data sources as well as automate and streamline cumbersome manual processes – benefitting our government customers by enabling them to better comply with regulations, protect sensitive information, increase operating efficiency, reduce data processing costs and improve the quality of information available to government employees and citizens.

Examples of our Alfresco experience and solutions can be viewed below:

Case Study: Department of Housing and Urban Development

Case Study: FederalConference.com

News Release: Gwinnett County and Alfresco