DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Container Services: Hello From the Outside!

Container Services: Hello From the Outside!

If you're building a complex application, then using a lot of microservices doesn't automatically make it simple. The complexity goes into the outer architecture. So how do we manage the complexity in the context of containers?

Jim Bugwadia user avatar by
Jim Bugwadia
CORE ·
Jun. 17, 16 · Opinion
Like (2)
Save
Tweet
Share
2.97K Views

Join the DZone community and get the full member experience.

Join For Free

Container Services are changing how applications are deployed and managed. But what exactly are they and how do they compare with other ways of delivering platforms?

Inner vs. Outer Services

Gary Olliffe, a research director at Gartner, published an insightful post titled "Microservices: Building Services with the Guts on the Outside"  that nails how the microservices architectural pattern deals with system complexity. In his post, Gary describes how in a microservices-style application, each service is designed to be as simple as possible to maximize developer productivity. However, the complexity has to go somewhere, and with the microservices approach, this complexity is pushed outside of individual microservices into a common layer of services.

Gary calls the (simpler) implementation of microservices the "inner architecture," and the layer where the complexity is pushed the "outer architecture." This classification gives us a nice model to work with to define Container Services.

Managing Application Complexity

So if the complexity is pushed outside of the application, who deals with it? Obviously, there needs to be some layer that handles the common services, i.e. "the plumbing" required for microservices.

There are a two emerging trends in how this new layer of platform services is delivered:

  • Application frameworks: Microservices frameworks are being developed for every major language. Java has NetflixOSS, Spring Boot and Spring Cloud (which abstracts some of the NetflixOSS components). Go has Go-kit, Micro, etc. Typically these frameworks are delivered as a set of language-specific libraries and runtime services.
  • Container Services: These are built on open container standards and are language or system agnostic.

Container Services

In mid-2015, several vendors in the container space launched the OCI (Open Container Initiative) under the Linux foundation. The goal was to address separation of vendor orchestration stacks and constructs, as well as OS-specific constructs, from container primitives.

Application containers are both an image packaging mechanism that describes what goes in an application component, and an application runtime which specifies how the application component is launched and executed. Not surprisingly, the OCI is working on two specifications: the OCI Runtime Spec, which deals with the application runtime, and the recently announced OCI Image Format Spec which covers the application definition and packaging.

The OCI standards now let us leverage the container as a standard unit of operations and management and build common application services around the container.

Container services build on open container standards and provide common application services outside of the container.

Some examples of where Container Services can help are:

  • Container lifecycle management.
  • Container scheduling and placement.
  • Logging.
  • Monitoring.
  • Auto-recovery
  • Auto-scaling.
  • Registration and discovery.
  • Load balancing.
  • Request routing.
  • Networking.
  • Storage and data management.
  • Application security.

Not all of these are directly related to microservices. Others like service discovery and version-aware request routing are necessary for building microservices-style applications. In fact, in the journey to cloud-native, a best practice is to decouple the application from the underlying infrastructure, and even traditional applications that are deployed in containers can greatly benefit from these services.

Choosing an Approach

So, circling back to Gary's point on pushing complexity outside of the microservice — we now have a couple of approaches to consider:

  1. The traditional approach of application frameworks, with language specific libraries and runtime components.
  2. Container Services that build on open container initiatives.

While there is no right or wrong approach, it is important to understand the tradeoffs between the two approaches. Also, container orchestration and management tools, as well as application frameworks, will provide varying degrees of support for platform services. In fact, in many cases, you may end up with a mix of application frameworks and container services to cover everything that is needed to deploy and operate microservices-style applications in production.





Application Frameworks

Container Services

  • Compile-time coupling with the application
  • Run-time coupling with the application
  • Language specific libraries
  • Language agnostic
  • Can be easier for developers to try via APIs
  • Requires a container runtime
  • Executes in the application (at least partially)
  • Executes outside of the application
  • Can be highly optimized for specific use cases
    (e.g. NetflixOSS)
  • Broader usage – less scope for optimization of certain use cases.
  • Fewer architectural layers
  • More architectural layers
  • Harder to enable polygot microservices (once a mass of libraries are built for a language)
  • Easier to enable polygot microservices
  • Changes to the “outer layer” will likely requires
    changes in the application
  • Changes to the “outer layer” do not require application changes.
  • Upgrades to the “outer layer” will likely requires
    an application upgrade.
  • Upgrades to the “outer layer” do not require an application upgrade.


SUMMARY 


While it is possible to design microservices applications that have compile-time integrations with platform frameworks and services, using containers provide several benefits. In addition to the agility and runtime portability, containers also make it possible to leveraging a standard layer of  platform services that cleanly address several challenges in building, deploying, and operating for cloud-native applications.What’s even better, is that a number of these Container Services are themselves deployed and orchestrated as a set of system containers, allowing for additional ease of management and true multi-cloud application delivery and management.Container Services help you reduce the application code you need to maintain and upgrade. Adding dependencies to an application should be done with care. In a few cases, it makes sense to compile-in common services and manage dependencies, versioning and upgrades. However in general my recommendation would be to push as much as possible to the “outer” architectural layer — outside your application and outside of the application container!

Interested in learning how Nirmata builds on open containers to provide adaptive cloud-native application management? Visit us at nirmata.com or explore Nirmata with a 15 day free trial.


Container microservice application

Published at DZone with permission of Jim Bugwadia, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Submit a Post to DZone
  • Top Three Docker Alternatives To Consider
  • The Quest for REST
  • How To Create and Edit Excel XLSX Documents in Java

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: