How to Understand Monolithic Versus Microservice Based Development

Executive Summary

• Most development has been performed following a monolithic approach.
• Cloud databases and microservices are changing this development paradigm towards being data-centric.

The Application Versus Data Centric Models

Both AWS and Google Cloud do perform development and are leaders in the software industry. However, in the traditional sense, they are not vendors as they use software to sell access. This distinction between being a software vendor instead of selling access to computational “things” has important implications for the approach that it allows customers to take in managing their IT expenditures. One of the most significant changes relates to the ability to become data-centric rather than application-centric, which for those interested can read about this in the article How AWS and Google Cloud Enabled Data Centric Development.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Containerization and Microservices

No discussion of the future of SaaS/PaaS/IaaS is complete with an analysis of containerization and microservices. Therefore we will begin by explaining what microservices are and how they work.

Microservices

Microservices break up the functionality that is generally contained within a monolithic application and monolithic database into smaller pieces, increasing the variety in coding languages, databases, and associated tools.

This is explained nicely in the following quotation.

“First, to be precise, when talking about microservices, we are actually referring to a microservice architecture. This architecture type is a particular way of developing software, web or mobile applications as suites of independent services – a.k.a microservices. These services are created to serve only one specific business function, such as: user management, user roles, e-commerce cart, search engine, social media logins, etc. Furthermore, they are independent of each other, meaning they can be written in different programming languages and use different data storages. The centralized management is almost non-existent and the microservices use lightweight HTTP, REST or Thrift APIs for communicating between themselves.”

Benefits of Microservices

With microservices, modularity is increased, as is developer specialization. As each microservice has its development, which is concentrated on the technologies and even the business processes for that microservice. New applications or new development will be increasingly likely to be based upon microservices. However, old applications are also being refactored into microservices to receive their benefits. Microservices are the opposite design of the monolithic design approach.

This is a slide from Chris Richardson, a well-known thought leader in the cloud field, which describes the monolithic design. The monolithic design requires a long-term commitment to a specific technology stack. This can be considered as a type of lock-in to the original design components.

With Issues that Surface As Programs Grow

The long life and “metastasizing” nature of computer programs, and particularly of successful programs, means that a monolithic design limits the flexibility of the program. This is because it begins with a series of development components that invariably would benefit from being altered/upgrades as time passes and new technologies become available. The monolithic design promotes the need for refactoring code rather than adding new microservices-based upon new technologies or adding microservices built on different technologies to address an increase in scope.

The objective is to make each component or microservice modular. This means that changes within the module can be tested without affecting the other modules. The API is the connection point to other applications or microservices.

Notice the API Gateway in AWS’s explanation of Lambda and DynamoDB.

Microservices Development

With microservices development, the modules have such a high degree of isolation that they can and often are written in different languages, with head microservice having its own database (allowing for different database designs). Creating such natural isolation in the design means that computer languages can be selected based upon the fit between the language and the purpose. This is particularly efficient because, in most cases, the different modules (application slices?) are maintained by different teams. This differs from a monolithic design like SAP, where the entire application is written in a single language and uses a single database. The monolithic design means forcing a single language. A single database type does things that they are not naturally good at keeping a single language throughout the application.

Microservices are enabled by containerization and use containers, containing a wide variety of items and even databases. Lynn Langit calls containers the new VMs, as her following quotation explains.

“To me, containers are the new VMs. All this frenzy about containers, and more specifically container management systems — look, somebody has to manage the things. I want to pay the cloud providers to do it so I don’t have to.”

Containers Explained

A container is a discrete encapsulated and emulated operating system that allows portability of codes and dependencies between physical or virtual/emulated servers.

Containers benefit from the automated management and performance benefits of container management systems like Docker. Docker is widely thought to have significantly simplified the usage of containers and increased the general usage of containers. Docker’s capabilities provide a higher incentive to use containers because of all the container management that comes with Docker.

Docker is only slightly less popular with programmers than this cartoon would suggest.

A great explanation of a container is as follows:

“Container-based development dictates the architecture of the application. In container-based development, the application is broken into small pieces (containers) that are replicated within the network. Each container is networked together so that if one is overloaded by a request, a copy of the container can step-in to handle the incoming requests while the overloaded container reboots and gets back online”

“Containers have impacts on the cost of managing resources credence as a way to build apps directly from the developer’s laptop with much of the process automated and packaged. They have impacts on the cost of managing resources”

These containers must be “orchestrated” (organized to work together), which is where Docker or the Docker Engine comes in.

Dockers Views

In Docker’s own words, the Docker Engine is the following:

“Docker creates simple tooling and a universal packaging approach that bundles up all application dependencies inside a container. Docker Engine enables containerized applications to run anywhere consistently on any infrastructure, solving “dependency hell” for developers and operations teams, and eliminating the “it works on my laptop!” problem.”

“Docker operates on top of the infrastructure and syncs with the way to ship, build, run and deploy applications. It’s an open platform for distributed apps. It works wherever Linux does, which is essentially anywhere; it also works on Windows. Docker is not reliant on a separate operation system; it just takes advantage of already built technology.” –

The rise of microservices and containers is evidenced by the fact that Docker is one of the fastest growing products currently in programming circles. Still, the overall use of containers, be it with Docker or Kubernetes, or AWS Container Service sees enormous growth.

Containers are described by Docker as follows.

“In a micro-services architecture, many small services (each represented as a single Docker container) comprise an application. Applications are now able to be deconstructed into much smaller components which fundamentally changes the way they are initially developed, and then managed in production.”

The Purpose of Containers

The entire purpose of the container is to launch microservices. These containers provide a high degree of autonomy. Moreover, this allows each container to use a different coding language. The reason this is beneficial is simple. Various tasks are better addressed with different coding languages.

For instance, our application, the Brightwork Explorer, which we show as a case study at the end of the book, only does math. Therefore we started the initial development and testing in R, which is better for early testing when the focus is on math. And then transitioned the code to Python when one wants to operationalize the math in an application (although Python has a lower overall math capability than R). These are two excellent languages for math, each with its advantages and disadvantages.

In addition to being written in any language or the best language for the task, microservices have the freedom to store data as is best for each microservice. This is why IaaS is such a boon for microservices (and vice versa). For instance, within Google Cloud’s App Engine (its PaaS), multiple microservices can be deployed within one App Engine, or as the following quotation explains, there is another option.

“If you don’t want to rely on these patterns to achieve isolation and you want a more formal enforcement of separation, you can use multiple App Engine projects. There are pros and cons to using projects instead of services, and you must balance the tradeoffs depending on your situation. Unless you have a specific need for one of the advantages offered by using multiple projects, it’s best to start with using multiple services within a single project because performance will be better and the administrative overhead will be minimized. Of course, you can also choose some hybrid of the two approaches. It means that the developers for each microservice can look at the full menu of storage and databases offered by the IaaS and pick and choose the best that meets the needs of the individual microservice. The performance implications are enormous, because under the monolithic development approach, the entire development team could only store data in the single database type, say the Oracle DB. Under the IaaS model, particularly with open source databases, there is little “fixed cost.” That is customers are charged by usage. This means any number of databases can be leveraged by any number of microservices.”

When is an Application Finished in Development?

The microservice architecture sees no endpoint for development. Microservices are a design that accounts for this continual development and effectively manages the long term growth and modification of the application.

When analyzed by those with the most in-depth understanding of software, it increasingly seems that software is like a “thing” at any one point in time. That is because of its constantly changing nature, constant maintenance and adjustment, and natural growth. It can also be viewed as a process—alternatively, a thing in process of becoming something else.

Many have compared software to a biological organism. It has a lifecycle. Parts of it are continually being updated, pieces being thrown away. This is how the developer sees the software, although the software user tends to view software as more of a “thing,” as they are not as privy to what goes on in the background.

What is the most accurate and functional mental model for software development and maintenance? One view is that the software development lifecycle has a definitive endpoint. This is what project managers would like people to believe. However, isn’t software more of a wheel, where further changes are implemented after maintenance, and the software evolves years after the initial go live?

Once one begins to consider software in an organic context, how does that alter how you build software? Monolithic vendors tend to present the go live as the end point. While this may sell well to corporate buyers, this is not a functional mental model that optimizes software development.

What Types of Development are Particularly Appropriate for Microservices?

Microservices are often more efficient for many development types (not necessarily all types) than the monolithic strategy where a single database and a single code base are used. This coordination of microservices is controlled by a service mesh, a “dedicated infrastructure layer built right into an app.”

This is explained in the following quotation from the Heroku blog.

“The first force that led to the surge in microservices was a reaction against traditional, monolithic architecture. While a monolithic app is One Big Program with many responsibilities, microservice-based apps are composed of several small programs, each with a single responsibility. This allows teams of engineers to work relatively independently on different services. The inherent decoupling also encourages smaller, simpler programs that are easier to understand, so new developers can start contributing more quickly. Finally, since no single program represents the whole of the application, services can change direction without massive costs. If new technology becomes available that makes more sense for a particular service, it’s feasible to rewrite just that service. Similarly, since microservices communicate across a language-agnostic protocol, an application can be composed of several different platforms – Java, PHP, Ruby, Node, Go, Erlang, etc – without issue.”

Adjusting from the Monolithic Model

The vast majority of applications that have ever been developed have been developed under the monolithic design. One might think, quite naturally, that because microservices are new that the majority of microservice applications are a new development. But in fact, the majority of containerized applications are legacy applications that have been ported to containers.

Monolithic designs can be created quickly but can have long term maintenance implications that were not considered in the development stage.

This is possible because conversion is possible from a monolithic application to containers without performing coding.

Monolithic designs have their place, and we are not covering this topic to treat them like a piñata. However, decades of history with the monolithic design have demonstrated some clear disadvantages.

• Code Redundancy: A monolithic application generates a lot of code redundancy. And to integrate with any functionality of a monolithic application, one must integrate into the overall database of the “monolith.” However, if a monolithic application is broken into many microservices, those microservices can be connected to any other microservice. There is little dispute that this is a more flexible design.
• Decreasing Development Efficiency with Growth: Monolithic applications are quick to develop…in the beginning. However, as the application grows, the development slows, and the interdependencies increase, and the limitations of the approach quickly catch up with the software monolith. And the larger the application becomes, the slower the future development, and the more bugs begin to appear. Monoliths require more time analyzing code as it is more difficult for the programmers to understand. This is because it is far more challenging to control the interdependencies as the application or codebase grows. Unfortunately, in their haste to develop quickly, vendors often select the monolithic approach to hit the early deadlines to show fast progress.
• Lack of Tool Variety/Choice: Monoliths primarily use a minimal number of tools. This is a disadvantage. Monolithic designs use one database type, one coding language, etc.. This cuts out the leverage that comes from using multiple components. If we consider how languages are created, each computer language does some things better than others. In databases, no database performs all types of database processing equally well. Also, of course, different loads work better on some hardware configurations versus others (that one is easy for people to understand. The earlier two examples require more hands-on exposure but are just as relevant). The degree to which tools are limited is the degree to which the overall final application is limited. A perfect example of this is an ERP system, which is the mother of all monoliths. Moreover, this is an excellent time to take a slight detour to fully appreciate the scope of the ERP influence on software design.

Containers and Microservices Are the “New Shiny” (Actually No Longer New as “Serverless” is the True “New Shiny”) But Why Containers Are Not Unflawed

Containers and microservices have many advantages over the monolithic design. However, even if they offered nothing but benefits and no disadvantages, there would still be costs in adjusting to these newer technologies.

This is emphasized in the following quotation.

“Just as container management systems present new sets of questions, so too do new organizational structures. If a company decides to adopt Holacracy as part of its mission to improve agility, it will have to navigate and structural change happens through experimentation, failure, and adaptation.”[i]

Companies have reported shortages of skills in this new way of performing and managing development. There is simply a lot to keep up with for all the changes in the programming space.

Of course, as with anything new, not everything is roses. And we would be remiss if we did not include this cartoon on microservices versus the monolithic approach.[i] [ii]

Custom Development Powered Up By Cloud Services

As distributed applications are accessing multiple databases, are we entering a period where the pendulum switches to custom coding again? Under the SAP or Oracle paradigm, you accepted the databases that were “approved” by SAP and Oracle. All competition was driven out of the process. Oracle applications worked with the Oracle database. For the longest time, SAP worked with Oracle database and only a handful of other closed source databases. But even this limited competition was not good enough for SAP. SAP finally decided to introduce HANA to push the Oracle database out of “their” accounts. SAP now thinks that all SAP applications should sit on an SAP HANA database.

While Oracle and SAP are trying to convince their customers to use only one type of database, AWS and Google Cloud offer a kaleidoscope of different database options. Werner Vogels describes a combination of components that are selected and stitched together. Most of these databases are open source. Moreover, one can choose from AWS’s wide variety or a smaller number offered by Google Cloud.

AWS and Google Cloud’s entire approach regarding the multibase is inherently contradictory to monolithic packaged applications because the packaged application uses one database and works in a particular and defined way. We will cover this topic, including containers and microservices, later in the book.

But for now, and to keep with the continuity of the chapter, let us move onto the benefit that AWS and Google Cloud provide for deployment speed.

AWS and Google Cloud For Speeding New Development

A significant distinction between AWS and Google Cloud versus Oracle and SAP is the speed at which AWS and Google Cloud can develop and market new offerings. Basically, they can conceive of it, test it, and then add it as an offering to the AWS and Google Cloud sites. The on-premises vendors have to go through a much longer cycle. Then they have to educate salespeople to push concepts. The entire SAP/Oracle model is around lengthy sales cycles, exaggerated claims, and lengthy implementations, with outcomes that don’t match the sales cycle’s promises. AWS and Google are some of the few enterprise participants who seem to communicate and initiate principally through their website. We learn about AWS and Google Cloud through their website, not through calling up sales reps.

How AWS and Google Cloud Educates on Cloud

As a research entity, we/Brightwork Research & Analysis are very focused on documentation. So how do AWS and Google Cloud measure up?

Let us review the information.

• AWS does a great job of explaining what cloud computing is. AWS’s documentation is first rate and their presentations very matter-of-fact and honest as to what they offer.
• Google Cloud also creates excellent documentation, and every service opens to documentation to get into more detail.
• AWS and Google Cloud are also easier to understand and follow because it lacks the heavy involvement from marketing. Secondly, another positive aspect is that because neither AWS nor Google is vendors, they have less incentive to cover up shortcomings or issues with the software.

The combination of the ability to find out about services online, to test services using AWS and Google Cloud’s ready to go infrastructure, the ability to close down services at will, the excellent documentation and training all increases the ability to bring up all the supporting components and to speed development. Furthermore, during development, AWS and Google Cloud allow for the easy sharing of developed items. Once the development is ready for user testing (As we cover at the end of the book in our case study on bringing the Brightwork Explorer application to AWS.), one can receive feedback through sharing the application link rapidly. We quickly got our application up and running without worrying about code optimization or hardware sizing. With the elastic capabilities of AWS and Google Cloud, we knew we could increase our capacity at any time. Under AWS and Google Cloud, the entire development process is made more efficient. In fact, at this point, we can’t see developing without leveraging either AWS or Google Cloud. It is a new day for software development.

References

[i] The Docker and Container Ecosystem – https://thenewstack.io/ebooks-thank-you

[i] https://turnoff.us/geek/are-you-ready-for-microservices/

[ii] This issue highlighted in the cartoon is related to the findability of microservices. The obvious solution is a directory. This is addressed by Netflix, one of the leaders in the use of microservices, in the following quotation. “One of the problems introduced by microservices is the large volume of services that must invoke other services in the system. Each of these services must know where to find the services it consumes, and attempting to manage the resulting configuration manually is intractable. To solve this problem, Netflix created the Eureka server. A Eureka server is a service registry. It’s like a phone book for your microservices. Each microservice registers itself with Eureka, and then consumers of that service will know how to find it. This is similar in spirit to a DNS service but with additional features such as host-side load-balancing and region-isolation. Eureka also keeps track of health, availability, and other metadata about the service. That makes it an ideal place to start when building your own microservices architecture.” – https://blog.heroku.com/managing_your_microservices_on_heroku_with_netflix_s_eureka