<div style="display:inline;"> <img height="1" width="1" style="border-style:none;" alt="" src="//googleads.g.doubleclick.net/pagead/viewthroughconversion/995099146/?value=0&amp;guid=ON&amp;script=0">
Microservices and Containerization Blog Feature
John Zimmerer

By: John Zimmerer on January 22nd, 2016

Print/Save as PDF

Microservices and Containerization

Customer Experience

For the past couple of decades, the most common way for enterprise software to be developed and sold was as monolithic packaged applications and even larger platforms – all fully built and integrated in a big chunk. More recently, due in large part to the growth of cloud computing, agile development processes, and the need for lightweight, virtualized applications and enterprise architecture flexibility, the movement has been toward microservices and containerization.

What Are Microservices and Containerization?

Microservices is an approach to application development in which a large application is built as a suite of modular services. Each module supports a specific business goal and uses a simple, well-defined interface to communication with other modules. (Source: TechTarget)

A container is an isolated guest in container-based virtualization. Container-based virtualization uses a single kernel to run multiple instances of an operating system. Each instance runs in a completely isolated environment, so there is no risk that one container can gain access to another’s files. (Source: TechTarget)

Microservices and container technologies have become hot trends in software development over the last couple of years. Why? Because, as Luke Marsden explains for InfoQ, microservice architectures used in combination with containers allow developers to “decouple software into smaller functional pieces,” and containers “extend this decoupling, separating software from the underlying hardware.”

Benefits include increased development speed and aptitude for change, along with the ability to deliver better and faster updates. This results in more resilient, scalable and portable solutions. Moreover, when a single module fails, the larger application can remain largely unaffected.

The good news is, if you’re already using RESTful services with service-oriented architecture (SOA), like we at Topdown are, it’s a short hop to microservices.


Flexibility of Purchasing and Using Microservices

Topdown has adopted a microservices and containerization approach to the development of our new CCM solution. We are developing the software using Docker containers on Amazon Web Services. That’s not the only deployment model that could be used, though. Once you port your services to other containers, you have flexibility of deployment.

This aligns very well with our agile development process, and it will give our customers many options for deployment and use. You’ll be able to decide how and how much the application gets integrated into your enterprise architecture. Right now, you probably don’t have that flexibility because most enterprises are still buying packaged applications, so they’re deploying applications instead of services. In the future, you’ll be buying modular services and deploying them as services within your architecture. We’re preparing for that future now, which will give our software greater longevity and our customers a better return on their investment.

What Microservices Will Do for Topdown and Our Customers

  • It will allow us to participate in the container revolution so we can provide deployment flexibility both inside and outside the firewall; some, no or all apps could be running in the cloud or behind a firewall, depending on the organization’s needs and architecture.
  • We’ll be able to offer much more functionality on demand. For example, we could choose to sell just our document designer application, or just our history functionality, etc. Again, the goal is to provide flexibility in the future to deploy our software in more discrete, componentized services if needed. By building the application as a collection of services, we’re designing for external applications to do the same thing, increasing interoperability and integration capabilities with the rest of an enterprise’s customer experience management portfolio.

Want to join the conversation? Tell us what you think is the future of customer experience enterprise architecture by joining our CX Architects group on LinkedIn.

Subscribe to the blog now