The InfoQ Architects Newsletter is just over one year old! In our thirteenth issue we are exploring container orchestration and scheduling. With the increasing uptake of public cloud across the IT landscape, combined with the emergence of additional "cloud native" architecture patterns and technologies like containers, it is fast becoming essential for architects to gain a better understanding of this space.

News

Packaging Applications for Docker and Kubernetes: Metaparticle vs Pulumi vs Ballerina

In a recent InfoQ article, Lakmal Warusawithana discussed how the uptake of microservice architecture is further driving the software industry towards cloud native application development and deployment. Docker and Kubernetes are the key elements of modern cloud native deployment automations, and the current best practice for deployment is to create reproducible packages for applications with containers. However, this typically involves the manual writing (and maintenance) of YAML deployment descriptors.

Metaparticle, Ballerina, and Pulumi are three open source projects that introduce their own approach to solving the problem of packaging applications for deployment using Docker and Kubernetes. The article provides several working examples, and documents the steps necessary to deploy a simple "HelloWorld" application using each of the frameworks.

"Docker Application Guides" Demonstrate How to Deploy Enterprise Apps to Swarm and Kubernetes

Docker Inc recently announced Docker Application Guides, which demonstrate how to deploy applications on Docker Enterprise Edition (Docker EE) and Docker Desktop, providing architecture examples and guidance for selecting container images and deploying prototype applications, orchestrated by Docker Swarm or Kubernetes. In related news, Docker Desktop has officially added Kubernetes support to the stable release of the tool for Windows and Mac.

The creation of the Docker Application Guides is part of the outcome of Docker's Modernize Traditional Applications (MTA) program, the goal of which is to take existing applications that are running in enterprise organizations and bring them to Docker, without extensive rewrites or refactoring.

Introduction to HashiCorp Nomad

HashiCorp Nomad is an open-source container (and other workload) orchestration tool that aims to reduce the complexity of automating, scheduling, and rescheduling application deployment. In a recent video, HashiCorp co-founder and CTO Armon Dadgar provided a brief whiteboard introduction to Nomad, including: how to rethink the traditional deployment pattern, without changing everything; how Nomad lets developers submit job deployment requests to Nomad, rather than making a request to the operations/platform team; and how Nomad can potentially simplify high-performance computing - e.g., scheduling 40 million containers in minutes.

Christie Koehler has also recently written about "Building Resilient Infrastructure with Nomad: Restarting tasks" on the HashiCorp blog, which includes example code and detailed instructions for experimentation.

Debugging Microservices in Containers: Squash vs Telepresence

Anita Buehrle has recently written an article on the Weaveworks blog that discusses how to debug container-based microservices using the Squash and Telepresence tools. Squash is deployed to a Kubernetes cluster as a server and a Daemonset with an IDE acting as the UI for Squash. An IDE can be used to attach to one of the running pods on which to start a debug session. With Telepresence, a running service in Kubernetes is swapped out and replaced with a proxy to a local process running on a developer's laptop. This gives the local service that is being worked on full access to the ConfigMap, secrets, as well as to the other services running on the remote cluster.

As it currently only supports VS Code and IntelliJ, Buehrle concludes that Squash is dependant on an IDE. More integrations are planned, however. Telepresence is potentially more flexible, as it supports other debuggers in addition to those that are integrated with an IDE. Telepresence also goes beyond debugging and allows a developer to test and run services from their local environment on the fly, which enables live coding of applications running in a cluster.

Google Releases Knative: A Kubernetes Framework to Build, Deploy, and Manage Serverless Workloads

At Google Cloud Next 2018, the release of Knative was announced as a "Kubernetes-based platform to build, deploy, and manage modern serverless workloads". The open source framework attempts to codify the best practices around three areas of developing cloud native applications: building containers (and functions), serving (and dynamically scaling) workloads, and eventing. Knative has been developed by Google in close partnership with Pivotal, IBM, Red Hat, and SAP.

Knative (pronounced "kay-nay-tiv") provides a set of middleware components that are "essential to build modern, source-centric, and container-based applications" that can run on premises, in the cloud, or in a third-party data center. The framework is the open-source set of components from the same technology that enables the new GKE serverless add-on.

Container Communication: The Rise of the Service Mesh

Implementing effective networking and communications within a container-based environment is nontrivial due to the inherent complexity of multiple abstractions, many moving parts, and the ephemeral nature of the underlying platform. The term "service mesh" has been created to group together a number of network proxy-based implementations that attempt to overcome these challenges. Technologies within this space include Envoy, Istio, Cilium, NGINX nginMesh, and Consul Connect.

InfoQ has recently published a free eMag, "Service Meshes: Managing Complex Communication within Cloud Native Applications", which provides a guide to the problem space and summary of current work. The microXchg conference talk recording of an introductory presentation by Daniel Bryant has been published on InfoQ: "What is a Service Mesh, and Do I Need One When Developing Microservices?". Matt Klein's QCon NY talk recording of Lyft's usage of Envoy has also been made available on InfoQ: "Lyft's Envoy: Embracing a Service Mesh".

Case Study

Shopify's Journey to Kubernetes and PaaS: Niko Kurtti at QCon NY

At QCon New York, Niko Kurtti presented "Forced Evolution: Shopify's Journey to Kubernetes", and described the Shopify engineering team's journey to building their own PaaS with Kubernetes as the foundation.

At the start of 2016 the engineering team was "running services everywhere", including within their own data centers (using Chef and Docker), on AWS (using Chef) and Heroku. Developers liked the developer experience of Heroku, and Kurtti commented that this platform actually scales quite well, with "simple UI sliders" to increase the number of instances and associated CPU and RAM. Although the platform team had defined service tiers and appropriate Service Level Objectives (SLOs) based on criticality to the business, there were many processes that were not scalable, and accordingly these presented challenges as the company grew.

The Shopify engineering team recognised that they needed to build an internal Platform-as-a-Service (PaaS) in order to standardise both the developer experience and the operational requirements. The three principles that were key to the success of the PaaS included: providing a "paved road" -- operating a platform that would, by default, meet a high percentage of use cases within Shopify, but also allow customisation if required (the Netflix engineering team discussed a similar concept at last year's QCon New York); complexity should be hidden -- there are advantages to knowing about the underlying platform, but many developers do not want to be exposed to all of the details of the internals; and self-service is a priority -- developers should not be bottlenecked by waiting for centralised operations or platform teams.

After analysis and experimentation the Shopify team chose to build their PaaS on top of the Kubernetes container schedulers and orchestrator. Kubernetes had the best traction of the open source projects within this space, it was platform agnostic, it could be extended via the APIs exposed, and it was also offered as a service in GCP -- Google Container Engine (GKE) -- which allowed the team to focus on the value-adding components they could provide on top on this "strong foundation".

The platform team has invested heavily in the creation of "cloudbuddies", which are effectively custom extensions on Kubernetes in much of the same style as CoreOS's Operator pattern. Cloudbuddies extend the Kubernetes API and manage processes such as creating DNS records, configuring cluster/user quotas, and setting security rules. The cloudbuddies have been highly influential on the success of the new platform, and Kurtti discussed how extending Kubernetes has been generally a good experience.

The platform team does not currently expose the Kubernetes control plane to developers, and instead of using tooling like kubectl, they deploy and operate applications via the provided web UI. This UI provides the majority of functionality that kubectl does, and in the future kubectl itself may be exposed to "power users" within the development team. Extensive documentation and training is provided for developers wanting to use the PaaS.

A comprehensive summary and the complete video recording of Niko Kurtti's QCon New York "Forced Evolution: Shopify's Journey to Kubernetes" can be found on InfoQ.

To get notifications when InfoQ publishes content on this topic follow Containers on InfoQ.

Missed a newsletter? You can find all of the previous issues on InfoQ.

This edition of The Software Architects' Newsletter is brought to you by:

Why NoSQL?

Due to the shortcomings of relational databases, NoSQL databases are rapidly emerging as the preferred alternative for enabling systems of engagement and real-time applications. Indeed, NoSQL databases provide significant advantages:

Scalability - A NoSQL database can scale horizontally, enabling applications to run in parallel on a cloud-based cluster comprising dozens, hundreds, or even thousands of commodity servers. NoSQL databases can also scale up to exploit new hardware like SSDs (solid-state drives) and transactional memory.

Flexibility - A schema-less NoSQL database can process and store structured, unstructured and semi-structured data, and enable flexible and rapid development of applications and use cases such as right-time decisioning, recommendations, profile management, bidding, and risk profiling.

InfoQ strives to facilitate the spread of knowledge and innovation within this space, and in this newsletter we aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We aim to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices, and are always keen to receive feedback from our readers. We hope you find it useful, but if not you can unsubscribe using the link below.

Forwarded email? Subscribe and get your own copy.