We need to talk.
No, really—one of the hardest parts of wrapping your head around the complexities of CloudNative is getting a handle on all the lingo. Containers, microservices, and orchestration, oh my! When Container Solutions staff meet with clients, we often find that the best place to begin is with a quick Cloud Native 101 to make sure we are all talking about the same things in the same way.
Similarly, when we do trainings, we provide pre-training materials so participants less versed in this new technology can get up to speed on the fundamentals before going hands-on in a workshop.
So here is run-down on some essential Cloud Native terms and concepts. If you are already familiar with many (or even all) of them, it’s still a handy resource to share with those who aren’t. After all, a shared vocabulary is helpful when talking with managers, executives, or anyone else in your organisation who needs to understand why it’s time to get on board with Kubernetes—and all that comes with it.
Cloud computing, or ‘the cloud’ is a general term for delivering hosted services over the internet. Cloud services are different from traditional infrastructure and platform hosting because they are elastic (users can employ as much, or as little, service as they need at any given moment); sold on demand (by the minute or the hour); and fully managed by the provider (requires nothing but a computer and Internet access). Significant recent innovations have accelerated interest in even smaller enterprises moving to cloud computing. See also: Private Cloud, Public Cloud.
Specifically, the automation of server configuration and management, using tools such as Ansible, Puppet, Chef, or Terraform.
Containers are lightweight, standalone executable software packages that include everything required to run an application: code, runtime, system tools, libraries, and settings. They are a sort of ‘standard unit’ of software that packages the code with all its dependencies so it can run anywhere, in any computing environment.
Continuous Integration (CI) is a development approach where teams implement small changes and check in code to version control repositories frequently so that the codebase is constantly iterated and updated. The technical goal of CI is to establish a consistent and automated way to build, package, and test applications.
Continuous Delivery (CD) starts where Continuous Integration ends. CD automates the delivery of CI’s small, iterative changes to run on cloud-based infrastructure. Most teams work with multiple environments outside the production pipeline, such as development and testing environments, and CD ensures there is an automated way to push code changes to them. CD automation then performs any necessary service calls to web servers or databases, and executes procedures when applications are deployed.
When integrated, CI/CD together make it possible to implement Continuous Deployment. Continuous Deployment is a key Cloud Native element where application changes run through the CI/CD pipeline and passing builds get deployed directly and seamlessly to fully automated production environments. Teams practicing Continuous Delivery elect to deploy to production on daily or even hourly schedule.
A cross-functional team is where members have different skill sets and competencies, but are working collaboratively toward the same goal. Team members have all competencies necessary for accomplishing the work within the team—so there are no dependencies on others outside the team. In software development this typically means frontend and backend developers, database and UX specialists, QA engineers, and any other role necessary for producing the product/service.
It's how individuals within an organisation communicate and work with each other. Culture is the sum of the daily actions that you take, your routines. If you talk to people as part of doing your work, you have collaborative culture. Needing to seek permission before trying something new means you have hierarchical culture. If you change the actions, you change the culture.
Data-driven design describes the practice of developing or improving a product based on things you can measure. Metrics like site analytics, carrying out A/B testing, or surveying users for feedback are all used to make design decisions.
Design thinking is a human-centred approach to business processes. It focuses on customer problems and challenges as the foundation to producing products and services that satisfy their wants and needs, and is an excellent tool to combine with Cloud Native development processes.
DevOps is both a culture and set of processes aimed at reducing the division between software development and its actual operation. With DevOps, the traditionally siloed Development and Operations teams work together as one cohesive team (or, sometimes, two teams in tight collaboration). The approach facilitates fast and seamless software development while optimising both productivity and reliability. Companies adopting the DevOps model create teams that embrace the entire development and infrastructure lifecycle in their scope of responsibility. See: SRE.
Greenfield deployment refers to building a complete software development system where previously there was none. In Cloud Native it means not just cloud-based infrastructure but also incorporates architecture, design, process, and culture—basically, starting completely from scratch in every possible area. Greenfield development is often viewed as advantageous because it is free from constraints that can be imposed by a system’s existing networks/infrastructure.
Microservices (microservice architecture) is an approach to application development in which a large application is built as a suite of modular components or services. Each service runs a unique process and usually manages its own database. A service can generate alerts, log data, support UIs and authentication, and perform various other tasks.
Microservices enable development teams to take a more decentralized (nonhierarchical) approach to building software. Microservices enable each component to be isolated, rebuilt, redeployed, and managed independently.
‘Monolith’ is used to describe a single-tiered software application in which different components combine into a single program, launched from a single platform. A monolithic application is self-contained, and independent from other computing applications, its design based on a ‘batteries included’ philosophy that makes the application responsible not just for one particular task, but can perform every step needed to complete any function. Monolithic apps are huge and complex, and therefore very slow to deliver changes/supdates; a typical development cycle is six months to one year.
Orchestration in general refers to the automated configuration, coordination, and management of computer systems and software. In cloud computing, it refers more specifically to orchestrator tools. The best known is Kubernetes, an open-source system for automating the deployment, scaling, and management of containerised applications.
In Cloud Native, orchestration is all about managing the lifecycles of containers, especially in large, dynamic environments. (Dev)Ops teams use container orchestration to control and automate tasks such as the availability, provisioning, and deployment of containers, load balancing of containers across infrastructure, and scaling up/down by adding/removing containers as needed. See also: Containers.
Public clouds like Google Cloud and Amazon Web Services sell services to anyone, and all users share the same resource pool. A private cloud is a proprietary network, usually company-owned, with access limited to specific entities.
SRE, which stands for Site Reliability Engineering, evolved independently of the DevOps movement but fits perfectly with it. SRE embodies the DevOps philosophy and then takes it one step further to define an architecture for implementing them. SRE offers a much more prescriptive way to measure and achieve reliability across the full spectrum of DevOps responsibilities. DevOps is a philosophy; SRE is a set of practices. SRE is typically the desired model in very large frameworks, like Google.
The Waterfall model of software development is based on a logical progression of steps that form the software development life cycle. One follows after the other in strict order, much as a waterfall cascades down from top to bottom. While the rise of Agile methodologies have and caused Waterfall model to decline in popularity, Waterfall’s sequential process still contains advantages and it remains a common design process in the industry.
We have our first-ever book coming: 'Cloud Native Transformation: Practical Patterns for Innovation'. Click below to pre-order now!