Cloud-native applications, Microservices and Containers

In days bygone when terms like “cloud-native” were not part of IT lexicon, a traditional eCommerce application might have had a client application (traditional web app using HTML) talking to a server process where the web application could consist of modules like Identity, Catalog, Ordering, Basket, Marketing and Location.  All these server processes would use a single relational database.  Over time companies realized that monolithic application made maintenance cumbersome and the introduction of new functionality challenging.

In addition, traditional client web applications were joined by Mobile apps, Single Page Applications (SPA) web apps.  In this new model, the web application communicated via an API gateway to individual microservices for tasks like identify, Catalog, Ordering, Basket, Marketing and Locations.  Rather than relying on a single Relational database, this cloud-native application now had each micro-service using its own data store which could be anything ranging from a Relational to a NoSQL database.  These microservices in turn communicated with an event bus which acted as a publish/subscribe channel.

These micro-services were written using a variety of language and frame-works and ended up being packaged in light-weight containers rather than in virtual machines.  Now that each micro-service was maintained independently there was more efficient life cycle management of the entire application.

Containers were an evolution of virtual machines (VM).  Unlike a VM the containers didn’t install anything on the Operating system, they had shorter lifetimes, increased densities per host and a containerized application could start up almost instantly.

Security concerns around containers gave rise to an ecosystem of companies like TwistLock who identifies the expected behavior of a container and creates a white-list of processes, networking activities and storage practices so that any deviation from the baseline could be flagged as potentially malicious behavior.

Other ecosystem vendors like Polyverse took advantage of the fact that a container could start in a fraction of a second to relaunch containerized applications in a “good state” every few seconds.  This meant that a potential hacker wouldn’t have enough time to exploit an application running in the container.  Reminds you of jewel thieves using multiple getaway cars doesn’t  it?  Stay tuned for more on containers, Docker, Kubernetes next..