![3
Key Definitions: Microservice
‘There is not one single definition for the term “microservice,” two are very
helpful:
• Microservices are small, autonomous services that work together; and
• Loosely coupled service-oriented architecture with bounded contexts.’ [1]
Microservices is a style of Application Architecture, evolving from Service-Oriented
Architecture (SOA), designed to solve problems for systems that are ‘too big’.
They are really about replaceability not maintenability, a way of working with
systems in which scale is a predominant factor, focused on the goal of improving
changeability of these systems.
Microservices are typically composed into whole application solutions using
patterns of industry proven arrangement, just like SOA services. Patterns address
Deployment (more of which later), Communication, Service Discovery, Reliability,
Data Management, Observability, Security, Testing and so on. For example,
microservices should own and manage their own data. Databases can be sharded
to provide isolation within a shared RDBMS context, or be physically separate
stores of information. Regardless, the Command Query Responsibility Segregation
(CQRS) pattern will be an essential approach when writing queries across these
disparate data sources. [2]
[1] Microservice Architecture – Aligning Principles, Practices and Culture
Nadareshvili, Mitra, McLarty, Amundsen
Published by O’Reilly 06/2016
[2] Chris Richardson maintains the site microservices.io which has a great section on microservice patterns
http://microservices.io/patterns/index.html](https://image.slidesharecdn.com/microservicesdcontainersorchestrationprimer-170713220100/85/Microservices-Containers-Scheduling-and-Orchestration-A-Primer-3-320.jpg)
![4
Microservice Characteristics and Moving from Monolith to Microservice [3]
James Lewis and Martin Fowler provided a reasonable common set of
characteristics that fit most of the microservices architectures:
• Componentization via services
• Organized around business capabilities
• Products not projects
• Smart endpoints and dumb pipes
• Decentralized governance
• Decentralized data
management
• Infrastructure automation
• Design for failure
• Evolutionary design
Each microservice should have its own separate database,
or shard within a shared database
https://en.wikipedia.org/wiki/Shard_(database_architecture)
Most asked
question: How
do I evolve my
monolithic
(legacy)
database?
[3] Migrating to Microservices Databases – from Relational Monolith to
Distributed Data
Edson Yanaga
When developing a strategy for moving from Monolithic code and (relational) databases to
microservices and distributed data, there are some key undertakings:
• Implement the Strangler Pattern;
• Follow a Domain Driven Development approach;
• Ensure Zero Downtime by employing:
o Blue / Green Deployments; and
o Smart Canary Deployments via Smart Routers and / or Feature Toggles.
• Have a mature DevOps team and
culture;
• Have a mature CI/CD pipeline;
Another key element of each microservice is how to handle application state:
• transient or ephemeral – handle in memory during run with services like Redis or
Memcached so that there is no state loss during deployment given they back their in
memory caches with on disk storage;
• persistent – distributed databases, one per microservice, or isolated shard within a
single database i.e. as indicated by the Decentralised Data Management point above.](https://image.slidesharecdn.com/microservicesdcontainersorchestrationprimer-170713220100/85/Microservices-Containers-Scheduling-and-Orchestration-A-Primer-4-320.jpg)
Microservices, Containers, Scheduling and Orchestration - A Primer
- 1. MICROSERVICES, CONTAINERS, SCHEDULING AND ORCHESTRATION: A PRIMER G Llewellyn, July 2017 Enterprise, Solution and Cloud Architect 1
- 2. 2 Architectural Context Compute- as-a- Service Platform-as-a- Service Function-as-a- Service VMs Cloud and Managed Container Services Serverless Container Cluster Managers Container s Technology Domain Centralised Computing Distributed Computing Monolithic Microservices Functio n SOAClient Server Applications Domain ‘90s ‘00s ‘10s Today Mainframe Mini, Desktop Infrastruct ure-as-a- Service Owned Infrastruct ure
- 3. 3 Key Definitions: Microservice ‘There is not one single definition for the term “microservice,” two are very helpful: • Microservices are small, autonomous services that work together; and • Loosely coupled service-oriented architecture with bounded contexts.’ [1] Microservices is a style of Application Architecture, evolving from Service-Oriented Architecture (SOA), designed to solve problems for systems that are ‘too big’. They are really about replaceability not maintenability, a way of working with systems in which scale is a predominant factor, focused on the goal of improving changeability of these systems. Microservices are typically composed into whole application solutions using patterns of industry proven arrangement, just like SOA services. Patterns address Deployment (more of which later), Communication, Service Discovery, Reliability, Data Management, Observability, Security, Testing and so on. For example, microservices should own and manage their own data. Databases can be sharded to provide isolation within a shared RDBMS context, or be physically separate stores of information. Regardless, the Command Query Responsibility Segregation (CQRS) pattern will be an essential approach when writing queries across these disparate data sources. [2] [1] Microservice Architecture – Aligning Principles, Practices and Culture Nadareshvili, Mitra, McLarty, Amundsen Published by O’Reilly 06/2016 [2] Chris Richardson maintains the site microservices.io which has a great section on microservice patterns http://microservices.io/patterns/index.html
- 4. 4 Microservice Characteristics and Moving from Monolith to Microservice [3] James Lewis and Martin Fowler provided a reasonable common set of characteristics that fit most of the microservices architectures: • Componentization via services • Organized around business capabilities • Products not projects • Smart endpoints and dumb pipes • Decentralized governance • Decentralized data management • Infrastructure automation • Design for failure • Evolutionary design Each microservice should have its own separate database, or shard within a shared database https://en.wikipedia.org/wiki/Shard_(database_architecture) Most asked question: How do I evolve my monolithic (legacy) database? [3] Migrating to Microservices Databases – from Relational Monolith to Distributed Data Edson Yanaga When developing a strategy for moving from Monolithic code and (relational) databases to microservices and distributed data, there are some key undertakings: • Implement the Strangler Pattern; • Follow a Domain Driven Development approach; • Ensure Zero Downtime by employing: o Blue / Green Deployments; and o Smart Canary Deployments via Smart Routers and / or Feature Toggles. • Have a mature DevOps team and culture; • Have a mature CI/CD pipeline; Another key element of each microservice is how to handle application state: • transient or ephemeral – handle in memory during run with services like Redis or Memcached so that there is no state loss during deployment given they back their in memory caches with on disk storage; • persistent – distributed databases, one per microservice, or isolated shard within a single database i.e. as indicated by the Decentralised Data Management point above.
- 5. 5 Key Definitions: Container Containers are a method of operating system virtualization that allow you to run an application and its dependencies as resource-isolated processes. • You are able to package an application's code, configurations, and dependencies into easy to use building blocks. • Containers, coupled with automation methods, provide rapid, reliable and consistent deployments and provide fine grained control over infrastructure resources. • The result is environmental consistency, increased operational efficiency, developer productivity, and sound version control practices. A container need not be used for a microservice, but they are a good way to develop and deploy them. Containers are built from images - pre-built components that can be layered together to build up applications and dependencies. A prime benefit is that it is easy to “overwrite” an individual container with images while the application is still running – less scheduled downtime which means better business continuity. Containers can be clustered and their constituent (microservice) applications scheduled as a unit through Container Cluster Managers – broadly discussed under the topic Container Orchestration.
- 6. 6 Container Benefits • Agile application creation and deployment: Increased ease and efficiency of container image creation compared to VM image use; • Continuous development, integration, and deployment: Provides for reliable and frequent container image build and deployment with quick and easy rollbacks (due to image immutability); • Dev and Ops separation of concerns: Create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure; • Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud; • Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-prem, Google Container Engine, and anywhere else; • Application-centric management: Raises the level of abstraction from running an OS on virtual hardware to run an application on an OS using logical resources; • Loosely coupled, distributed, elastic, liberated micro-services: Applications are broken into smaller, independent pieces and can be deployed and managed dynamically – not a fat monolithic stack running on one big single-purpose machine; • Resource isolation: Predictable application performance; and • Resource utilization: High efficiency and density.
- 7. 7 Microservice Runtime Deployment Patterns / Architectures Microservices don’t have to use Containers – it’s an architectural style, not a technology. Microservices that use Containers provide OS level virtualisation when installed on bare metal… Containers, using a Container OS Microservices don’t have to use hardware virtualisation, but it brings many benefits and enables multi- tenancy and varying Guest OS’ and configurations. Hypervisor Host Operating System Hardware Virtual Machine Micro- service Bins/Libs Guest OS Micro- service Virtual Machine Micro- service Bins/Libs Guest OS Micro- service Bins / Libs Host Operating System Hardware MicroserviceMicroservice Container Engine Bins/Libs Microservice C Microservice B Microservice C Microservice C Microservice A Bins/ Libs Bins/ Libs Host Operating System Hardware …and can be combined with hardware virtualisation for further efficiency, with a measure of added complexity. Host Operating System Hardware Hypervisor Virtual Machine Guest OS Container Engine Bins/Libs Microservice C Microservice B Microservice C Microservice C Microservice A Bins/ Libs Bins/ Libs Virtual Machine Guest OS Container Engine Bins/Libs Microservice C Microservice B Microservice C Microservice C Microservice A Bins/ Libs Bins/ Libs
- 8. 8 Layered Container Technology Architecture Container Orchestration Container Engine Container OS Bins / Libs Microservi ce Container Application Support Services
- 9. 9 Container Landscape: A Rich, Rapidly Changing Picture , Alpine
- 10. 10 Limitations of Single Container Instances: The Need for Container Cluster Managers • Single point of failure; • Resource constraints; • No auto healing & autoscaling features; • Limited container orchestration features; and • Limited service discovery features. Container Engine Bins/Libs Microservice C Microservice B Microservice C Microservice C Microservice A Bins/ Libs Bins/ Libs Host Operating System Hardware Containers, using a Container OS Single Container Instances – despite the benefits, there are production issues which they can’t address stand alone:
- 11. 11 Orchestrating Container Clusters and Scheduling Applications: Container Cluster Managers Load Balancer Host Operating System Hardware Container Engine Bins/Libs Microservice C Microservice B Microservice C Microservice C Microservice A Bins/ Libs Bins/ Libs Host Operating System Hardware Agent Scheduler DNS Container Engine Bins/Libs Microservice C Microservice B Microservice C Microservice C Microservice A Bins/ Libs Bins/ Libs Host Operating System Hardware Agent Container Engine Bins/Libs Microservice C Microservice B Microservice C Microservice C Microservice A Bins/ Libs Bins/ Libs Host Operating System Hardware Agent Overlay Network Physical Network Container Cluster Managers provide the following benefits and capabilities: • Container grouping by namespace; • Container clustering by application component; • Application health checking; • Auto healing; Hosted Container Cluster Manager Reference Architecture • Horizontal autoscaling; • Domain naming and service discovery; • Dynamic load balancing; • Centralised log access; and • Multi-tenancy.CCMs should also be supported by: • Identity and authorization systems; and • Mounting storage systems.
- 12. 12 Leading Container Orchestration Technology: Docker Engine Swarm Mode Docker Engine Swarm Mode Features • Same API as Docker; • Built-in service discovery; • Mesh Routing; • Multi-host networking; • Rolling updates; • Integrates directly with Docker Compose; • Secure using TLS encryption; • Securely manage, transmit and store secrets between nodes. Services, Tasks and Manager Nodes • Services use a declarative model; • Deploy by submitting a service definition to a manager node; • Manager node dispatches units of work called tasks to worker nodes for execution; • A single elected manager node maintains the desired state of the swarm by performing orchestration and cluster management functions; • Agent on the worker node reports assigned task state to manager so desired state can be maintained. Swarm Mode vs. Standalone Containers • When you use Docker engines (Container Engine component of the Reference Architecture) without using swarm mode, you execute commands on standalone containers. • Docker engines, or nodes, using swarm mode participate in a managed and orchestrated cluster. • You can run swarm services and standalone containers on the same Docker instances. Docker Swarm and Docker Engine in Swarm Mode are not the same thing – the latter is an evolution of the former.
- 13. 13 Mesosphere DC/OS Leading Container Orchestration Technology: Mesosphere DC/OS Apache Mesos Marathon Container (Docker, rkt) Chronos HAProxy ZooKeepe r Kubernetes Docker Engine Swarm Mode Marathon and Docker Swarm Mode can operate concurrently on the same Mesos Cluster. Logical Component Stack Framework designed to simplify execution of long running applications in a clustered environment Open source load balancer and reverse proxy Open source, distributed and fault-tolerant scheduler open source cluster manager that simplifies running applications on a scalable cluster of servers e.g. Chronos e.g. Marathon e.g. Docker Containe r Mesosphere’s distribution
- 14. 14 Leading Container Orchestration Technology: Kubernetes Kubernetes is: • Portable: public, private, hybrid, multi-cloud • Extensible: modular, pluggable, hookable, composable • Self-healing: auto-placement, auto-restart, auto-replication, auto-scaling Service - logical set of Pods running somewhere in the cluster, all provide the same functionality, assigned a unique IP address. kube-proxy is responsible for implementing a form of virtual IP for Services Container (Docker) Labels applied to Pods Collections of co-scheduled Containers Cluster worker node Exposed by kube- apiserver as the main management point for the control plane kube- controller- manager manages the lifecycle of pods kube-scheduler assigns workloads to specific pods Node agent, ensures containers within pods are running and healthy Docker Engine (not in Swarm Mode!) Container resource & performance collator
- 15. 15 (Unordered) Container PaaS Vendor Landscape Vendor Product CCM Container s Commentary Cloud Foundry Foundation Cloud Foundry Diego Garden IBM, SAP, Pivotal base their PaaS strategy on Cloud Foundry. Cloud Foundry is an open source, multi cloud application PaaS governed by the Cloud Foundry Foundation – a Linux Foundation project. The software was originally developed by VMware and then transferred to Pivotal Software, a joint venture by EMC, VMware and General Electric. A commercial version called Pivotal Cloud Foundry (PCF) is available from Pivotal. It provides extra tools for installation and administration and a Marketplace of packaged offerings e.g Spring Cloud Services. Pivotal Web Services (PWS), however, is an instance of Pivotal Cloud Foundry hosted on Amazon Web Services (AWS). Uses the same OCI low-level container execution code as Docker and Kubernetes, so container images run identically across all three platforms. Amazon Web Services (AWS) EC2 Container Service (ECS) ECS, Blox Docker Images stored in the ECS Registry (ECR). CloudWatch for metrics monitoring. Can also be combined with other AWS services like IAM, VPC & ELB. AWS Simplified Workflow is also tightly integrated with AWS ECS to use Docker CLI commands (e.g. push, pull, list, tag). Blox is a collection of open source projects for container management and orchestration on Amazon ECS. Blox gives you more control over how your containerized applications run on Amazon ECS, enabling you to build schedulers and integrate third-party schedulers on top of ECS, while leveraging Amazon ECS to fully manage and scale your clusters. Docker Inc Docker Cloud Docker Engine in Swarm Mode Docker Docker Cloud uses the hosted Docker Cloud Registry, which allows you to publish Dockerized images on the internet either publicly or privately. Docker Cloud can also store pre-built images, or link to your source code so it can build the code into Docker images, and optionally test the resulting images before pushing them to a repository. Docker Cloud allows you to link to your infrastructure or cloud services provider so you can provision new nodes automatically. Once you have nodes set up, you can deploy images directly from Docker Cloud repositories. With Beta Swarm Mode, you can create new swarms from within Docker Cloud, register existing swarms to Docker Cloud, or provision swarms to your cloud providers. Once you’ve built an image, you can use it to deploy services (which are composed of one or more containers created from an image), or use Docker Cloud’s stackfiles to combine it with other services and microservices, to form a full application. Eldarion Eldarion Cloud Kubernete s + Kel Docker Kubernetes on GCP coupled with Kel (kelproject.com), a layer of Eldarion- developed open-source tools and components written in Python & Go to
- 16. 16 (Unordered) Container PaaS Vendor Landscape Vendor Product CCM Container s Commentary Flockport Flockport LXC Installer, Flockport Utility, FlockBox LXC Flockport Apps (LXC format) Flockport is a startup focused on building an App store based on LXC containers that users can deploy in seconds on any server, any cloud and any provider. Flockport is focused on simplicity, making things just work, giving users a cloud-like flexibility of portable instances and workloads that can be moved across servers easily. Flockport LXC Installer creates a fully functioning LXC out of the box, the Flockport Utility let's you view and download containers directly to your system from the Flockport App Store. Flockbox is a minimal VM that lets you use LXC and the Flockport App store in seconds. Images available for Virtualbox, VMware and KVM. Linux Containers (LXC) is an open source Linux container project. LXC is a container manager and provides a set of tools to manage containers, a wide choice of container OS templates and advanced networking and storage capabilities for things like cloning and snapshotting. DigitalOcean Droplet, Block Storage, Networking, etc. (typical IaaS services) Docker Swarm 1, Kubernete s, Mesos 2, Dokku OS Image (VM), Docker DigitalOcean is a cloud infrastructure provider which allows developers to build and deploy microservices by creating so-called Droplets (i.e. units of work) on their global cloud data centers, plus leveraging block storage and networking features. A droplet can be an instance of an operating system image, but also a Docker container application. DigitalOcean takes care of provisioning, monitoring and other platform requirements for the Droplets. It can be combined with different orchestration tools such as Docker Swarm, Kubernetes, Apache Mesos or Dokku (a Docker-powered mini-Heroku PaaS). Therefore, DigitalOcean is more like a IaaS - comparable to AWS EC2 - but focusing on ease-of-use to deploy and run microservices clusters. Google Google Container Engine Kubernete s Docker Google Cloud Platform (GCP) contains Google Container Engine, amongst other services, a Kubernetes based cluster manager and orchestration PaaS for running Docker containers, providing flexibility to take advantage of on- premises, hybrid, or public cloud infrastructure. Google Container Registry makes it easy to store and access your private Docker images. Enable Stackdriver Logging and Stackdriver Monitoring with simple checkbox configurations, making it easy to gain insight into how your application is running. Container Engine is fully managed by Google reliability engineers, ensuring clusters are available and up-to-date, including both auto-upgrading and auto-repairing master and nodes. The Google Cloud Container Engine Service Level Agreement commitment is a Monthly Uptime Percentage to Customer of at least 99.5%. Reserve an IP address range for your container cluster, allowing your cluster 1 Not clear if this is Docker Swarm or Docker Engine in Swarm Mode 2 Not clear if this is Apache Mesos or Mesosphere DC/OS
- 17. 17 (Unordered) Container PaaS Vendor Landscape Vendor Product CCM Container s Commentary CoreOS Tectonic, Quay Kubernete s Docker CoreOS previously promoted fleet for distributed compute cluster management. They subsequently recognised Kubernetes as the de-facto standard, deprecated fleet 02/18. Quay is a secure container registry that builds and stores container images. Able to sync container images between data centres, automatically build and push images when developers commit code, automatically scan images for known security vulnerabilities etc. Tectonic includes Kubernetes installers to get up and running quickly, a console to visually investigate clusters, and security features to permit integration with existing security frameworks. Tectonic ships Operators in order to better manage its open source components, like Kubernetes, etcd, and Prometheus. Operators will be able to perform in-place updates, as well as backup, restore, and scale up and down instances of software as needed. A powerful, user-friendly console provides a full view of running apps, and deploy new versions using rolling upgrades, canary instances, and blue/green deployments. Available on bare metal or AWS - available in a free tier for small clusters. Deis Workflow, Helm, Steward Kubernete s Docker Deis builds open source tools for Kubernetes. Now acquired by Microsoft. Workflow – nginx, etcd, kubernetes, docker, core OS – integrated into a self service platform that makes it easy to deploy and manage container-based apps through a simple Heroku-inspired command line interface. Features such as user and log management, buildpack support, edge routing and easy release and rollback controls. Open source. Helm – package manager - helps you manage Kubernetes applications using Helm Charts (YML) to define, install, and upgrade complex Kubernetes applications. Charts are easy to create, version, share, and publish, provide repeatable application installation, and serve as a single point of authority. The latest version of Helm is maintained by the Cloud Native Computing Foundation CNCF.io - in collaboration with Microsoft, Google, Bitnami and the Helm contributor community. Steward – service broker - endpoint that manages a set of services. Now continuing evolutionary development under the service-catalog project (in incubation) to bring integration with service brokers to the Kubernetes ecosystem via the Open Service Broker API. Rackspace As yet unnamed, release ‘18 Q3+ Kubernete s Docker Carina (Magnum OpenStack, running Docker Swarm) killed April 2017 as it wasn’t aligning with the roadmap: managed Kubernetes service running on top of private OpenStack clouds, then bare metal, followed by layering the service on top of other Public Clouds. Kubernetes cluster federation opens up some interesting use cases for private/public deployments. Target of
- 18. 18 Container PaaS Vendor Landscape Vendor Product CCM Container s Commentary RedHat OpenShift Kubernete s Docker Provides a platform for provisioning, building, and deploying applications and their components in a self-service fashion e.g. the source-to-image (S2I) automated workflow which gets source code from version control to ready- to-run, docker-formatted (and thus portable) container images, integrating with CICD tooling on the way. Gives IT operations a secure, enterprise-grade Kubernetes that provides policy-based control and automation for applications, security features preventing tenants application or underlying host compromise. Support for stateless and stateful applications on a single platform due to ability to attach persistent storage directly to Linux containers. Other features: rich set of command-line tools; multidevice web console; Eclipse-based integrated development environments; CloudForms enables users to get real-time visibility into individual containers to the entire infrastructure; ecosystem of partners; can easily scale to thousands of instances across hundreds of nodes in a matter of seconds. Install OpenShift on OpenStack, AWS, Azure, GCP, VMware’s vCenter, https://blog.openshift.com/openshift-container-platform-reference- architecture-implementation-guides/ VMware Photon Platform, Photon OS Kubernete s, Cloud Foundry Docker Photon Controller sits between infrastructure and container cluster manager, similar to Mesos, it has a Service Manager and a REST API and is open source. Add Cloud Foundry and / or Kubernetes, then Docker containers and Harbor (container registry server). Features: A scale-out control plane that turns compute hosts into an easy-to-manage single system; Aggregates and exposes IaaS services for secure container and modern app runtimes via IaaS APIs; Simplifies deployment and life cycle management of compute, networking, security, storage and operations functions; Complete life-cycle management of advanced developer services (Kubernetes and Harbor) Photon OS – A lightweight open source operating system optimized for containers. All sits on VMware’s ESXi hypervisor for hardware virtualisation. Rancher Labs Rancher, RancherOS Docker Swarm 1, Kubernete s, Mesos 2, Cattle Docker Open source platform, takes virtual or physical Linux compute from any public or private cloud and implements a portable (container based) layer of infrastructure services designed for containerized apps, including networking, storage, load balancer, DNS, and security. Cattle is Rancher’s own CCM and is used to orchestrate infrastructure services as well as set up, manage, and upgrade Swarm, Kubernetes, and Mesos clusters. Application Catalog provides a one click deploy for an entire multi-container clustered app & perform fully automated upgrades. Public community catalog 1 Not clear if this is Docker Swarm or Docker Engine in Swarm Mode 2 Not clear if this is Apache Mesos or Mesosphere DC/OS
- 19. 19 (Unordered) Container PaaS Vendor Landscape Vendor Product CCM Container s Commentary IBM IBM Bluemix Container Service Kubernet es Docker Based on Cloud Foundry Deploy clusters into Bluemix Public cloud environment and connect to any service in the Bluemix catalogue and choose between dedicated or shared levels of hardware isolation for the worker nodes. Alternatively use Container Service in Bluemix Dedicated private cloud. Both leverage Bluemix Infrastructure (aka SoftLayer) resources. Store, share and restore data between pods with the integrated and secure volume service. Fully managed Kubernetes master that is highly available and continuously monitored by IBM. Image security compliance with Vulnerability Advisor - automatic scanning of images in your private and secure Bluemix image registry. Review recommendations specific to the operating system used in the image to fix potential vulnerabilities. Define custom policies to scale apps based on CPU and memory consumption. Use the cluster dashboard to manage cluster health and container deployments. Detailed consumption metrics via IBM Monitoring Service Review logging information using the IBM Logging Service to see detailed cluster activities. Private overlay networks with full load balancer and Ingress support to make your apps publicly available and balance workloads. Use a public IP, an IBM provided route, or own custom domain to access cluster services from the internet. Potential to integrate Bluemix services, such as Watson APIs, Blockchain, data services, IoT etc. Microsoft Azure Container Service, Azure Service Fabric, Docker Swarm 1, Kubernet es, Mesosphe re DC/OS. Azure Service Fabric Docker Docker Windows Developed in conjunction with Docker, PaaS can manage clusters of containers with “master machines” for orchestration i.e. any of Swarm, DC/OS or Kubernetes – you select the appropriate ARM template. Mesosphere Universe of services are included with ACS DC/OS deployment – permits addition of Spark, Hadoop, Cassandra etc. Microsoft Azure Service Fabric is a microservices framework and container orchestration engine. It is not dependent on Microsoft Azure, but also usable on premises and in other clouds (the term “Azure” is somewhat misleading). Service Fabric leverages Docker for container management on both Linux and Windows containers. It allows devs to use different programming languages (e.g. C#, Java, Powershell). Service Fabric powers many Microsoft services today, including Azure SQL Database, Cosmos DB, Cortana, Power BI, Intune, Azure Event Hubs, Azure IoT Hub, Dynamics 365, Skype for Business, and 1 This is legacy Docker Swarm - Docker Engine in Swarm Mode is not supported at the time of writing. If you want to deploy a Swarm mode cluster in Azure, use the open-source ACS Engine, a community-contributed quickstart template, or a Docker solution in the Azure Marketplace.
- 20. 20 Watching Brief – Container Initiatives – CNCF and OCI Cloud Native Computing Foundatio (CNCF) cncf.io Mission to create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self healing multi-tenant nodes. a) Container packaged. Running apps and processes in containers as an isolated unit of deployment, and achieve high levels of resource isolation. Improves development, fosters code and component reuse and simplifies cloud native application operations. b) Dynamically managed. Actively scheduled and managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the ops and maintenance costs. c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Increase app agility and maintainability of applications. CNCF will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces. Open Container Initiative (OCI) opencontainers.org, A Linux Foundation Project A lightweight, open governance structure (project) to create open industry standards around container formats and runtime. Launched ‘15 by Docker (who donated its container format and runtime, runC), CoreOS and other industry leaders, OCI currently contains two specifications: runtime-spec and image-spec. runtime-spec outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime. This workflow must support the ability to run an image with no additional arguments, thus: docker run example.com/org/app:v1.0.0 rkt run example.com/org/app,version=v1.0.0 To support this user experience the OCI Image Format contains sufficient information to launch the application on the target platform (e.g. command, arguments, environment variables, etc). This specification defines how to create an OCI Image, which will generally be done by a build system, and output an image manifest, a filesystem serialization, and an image configuration. At a high level the image manifest contains metadata about the contents and dependencies of the image including the content-addressable identity of one or more filesystem serialization archives that will be unpacked to make up the final runnable filesystem. The image configuration includes information such as application arguments, environments, etc. The
- 21. 21 Watching Brief – Rapid Changes – Recent Developments The technology in this space is changing very quickly – the crowded landscape grows more complex. However, it’s also very obvious that there are two de-facto technology approaches to containers & CCMs: Docker and Kubernetes As such, much of the recent innovation has taken place in relation to these technologies. Some recent developments include: • Kubernetes open source projects: o Ksonnet - A Jsonnet library that compiles Jsonnet code to Kubernetes YAML; o Kubeval - kubeval is a tool for validating a Kubernetes YAML or JSON configuration file; o Istio - An open platform to connect, manage, and secure microservices; and o Kubermesh - A bare-metal, self-hosted, self-healing, self-provisioning, partial-mesh network Kubernetes cluster! • IBM’s Microservice Builder developer.ibm.com/microservice-builder/ on Bluemix Container Service. By the time you read this, the landscape will have evolved further, so while the core principles remain the same, keep a watching brief over the technology.