13 Tools To Become Cloud Native
Tags: microservices, kubernetes
Published: 2020-10-30 09:50:38

![My Cloud Native Tools](https://dev-to-uploads.s3.amazonaws.com/i/zlokaaga02d46ufbtz7p.png)

_[The complete version of this article is available at Coder Society Blog](https://codersociety.com/blog/articles/cloud-native-tools)_

This is my list of cloud native tools. Companies that leverage the full suite of tools can often deliver faster, with less friction and lower development and maintenance costs.

Are we missing anything? Let me know!

### 1\. Microservices

[Microservices](https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices) scope product functionality into units that can be individually deployed. For example, in traditional pre-cloud-native deployments, it was common to have a single website service that managed APIs and customer interactions. With microservices, you would decompose this website into multiple services, such as a checkout service and a user service. Then, you could develop, deploy, and scale these services individually.\
Additionally, microservices are often stateless, and leveraging [twelve-factor applications](https://12factor.net/) allows companies to take advantage of the flexibility that cloud native tooling offers.

Recommended Technology: [Node.js](https://nodejs.org/)\
Alternative Technology: [Kotlin](https://kotlinlang.org/), [Golang](https://golang.org/)

### 2\. Continuous Integration / Continuous Deployment

[Continuous Integration / Continuous Deployment (CI/CD)](https://www.redhat.com/en/topics/devops/what-is-ci-cd) is an infrastructure component that supports automatic test execution (and optionally deployments) in response to version control events such as pull requests and merges. CI/CD enables companies to implement quality gates such as unit tests, static analysis, or security analysis. Ultimately, CI/CD is a foundational tool in the cloud native ecosystem that can lead to substantial engineering efficiencies and reduced error counts.

Recommended Technology: [Gitlab CI/CD](https://docs.gitlab.com/ee/ci/)\
Alternative Technology: [Github Actions](https://github.com/features/actions)

### 3\. Containers

Containers are at the heart of cloud native ecosystems and enable [unmatched velocity and quality gains](https://medium.com/dm03514-tech-blog/devops-containers-velocity-through-reduced-coordination-532f0ac000e5) by simplifying developer operations. Using containers with tools like [Docker](https://www.docker.com/), teams can specify their system dependencies while providing a uniform and generic execution layer. This layer enables infrastructure teams to operate a single infrastructure, such as a container orchestrator, like Kubernetes. Engineering teams can store container images in a container registry, which in most cases, also provides vulnerability analysis and fine-grained access control. Popular services for this are as [Docker Hub](https://hub.docker.com/), [Google Container Registry](https://cloud.google.com/container-registry), or [Quay](https://quay.io/).

Recommended Technology: [Docker](https://www.docker.com/)\
Alternative Technology: [Podman](https://podman.io/), [LXD](https://linuxcontainers.org/lxd/introduction/)

### 4\. Container Orchestration

Container orchestrators are tools for launching and managing large numbers of containers and remove the need for language-specific or team-specific deployment strategies. They allow users to specify a container image or group of images and some configuration. Finally, the orchestrators take these specifications and translate them into running workloads.\
Container orchestrators enable infrastructure teams to maintain a single infrastructure component, which can execute any container that adheres to the [OCI specification](https://github.com/opencontainers/runtime-spec/blob/master/spec.md).

Recommended Technology: [Kubernetes](https://kubernetes.io/)\
Alternative Technology: [Google Cloud Run](https://cloud.google.com/run)

### 5\. Infrastructure as Code

[Infrastructure as code](https://www.hashicorp.com/resources/what-is-infrastructure-as-code) is a strategy that puts cloud configuration under version control. Companies often manage their cloud resources manually by configuring them through an admin panel. Manual configuration, however, makes it hard to keep track of changes. Infrastructure as code addresses this by defining cloud resources as code and putting them under version control. Changes are made in the infrastructure config in code and promoted through the company's deployment process, which can include peer reviews, CI, and CD. Version control provides an audit log that shows who has changed which resources and when.

Recommended Technology: [Terraform](https://www.terraform.io/)\
Alternative Technology: [Pulumi](https://www.pulumi.com/)

### 6\. Secrets

[Secret management](https://www.hashicorp.com/products/vault/secrets-management) is essential for cloud native solutions but is often neglected at smaller scales. Secrets are anything private, such as passwords, private keys, and API credentials. At the very least, secrets should be encrypted and stored in configuration. Mature solutions enable temporary database credentials or rotating credentials to be issued, making secret management even more secure. Finding a fitting solution for secret management is vital for cloud native applications since containerized services scale horizontally and may be scheduled on many different machines. Ultimately, organizations that ignore secret management could increase the surface area for credential leakage.

Recommended Technology: [Vault](https://www.vaultproject.io/)\
Alternative Technology: [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets)

### 7\. Certificates

Secure communication over TLS is not only best practice but a must-have. This is especially important in container-based solutions because many different services may run on the same physical machine. Without encryption, an attacker who gains access to the host's network could read all traffic between these services. At the very least, it becomes untenable to manually update certificates for cloud native deployments, which is why some sort of automated solution is essential.

Recommended Technology: [cert-manager](https://github.com/jetstack/cert-manager)\
Alternative Technology: [Google managed certificates](https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs)

### 8\. API Gateway

API gateways are reverse proxies with features beyond traditional reverse proxies, such as [Apache](https://httpd.apache.org/) and [NGINX](https://www.nginx.com/).\
API gateways support:

-   Protocols like gRPC, HTTP/2, and Websockets
-   Dynamic configuration
-   Mutual TLS
-   Routing
-   Resiliency primitives, such as rate limiting and circuit breaking
-   Visibility in the form of metrics

Recommended Technology: [Ambassador](https://github.com/datawire/ambassador)\
Alternative Technology: [Kong](https://konghq.com/)

### 9\. Logging

Logging is a [foundational pillar of observability](https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html). Logging is often very familiar and accessible to teams, making it a great starting place to introduce observability. Logs are essential to understanding what is happening in systems. Cloud native tools emphasize [time series](https://grafana.com/blog/2016/01/05/logs-and-metrics-and-graphs-oh-my) for metrics, since they are more cost-effective than logs to store. However, logs are an invaluable tool for debugging, and some systems are only observable through them, which makes logging a requirement.

Recommended Technology: [EFK](https://www.cncf.io/blog/2020/07/27/logging-in-kubernetes-efk-vs-plg-stack/)\
Alternative Technology: [Loki](https://github.com/grafana/loki)

### 10\. Monitoring

Monitoring systems store important events as a time series. Monitoring data is aggregated, which means that you don't store all events. This makes it cost-effective for cloud native systems, and is essential for understanding the state of cloud native systems and answering these questions:

-   How many operations are occurring?
-   What is the result of the operations (success, failure, or status codes)?
-   How long do operations take? 
-   What are the counts of important resources such as queue depths or thread pools? 

You can assign different dimensions to monitoring metrics to drill into performance on an individual machine, operating system, version, etc.

Recommended Technology: [Prometheus](https://prometheus.io/)/[Grafana](https://prometheus.io/docs/visualization/grafana/)\
Alternative Technology: [Datadog](https://www.datadoghq.com/)

### 11\. Alerting

Alerting makes logs and metrics actionable, notifies operators of system issues, and pairs well with time series metrics. For example, alerts can notify teams when there is an increase in HTTP 500 status codes or when request duration increases. Alerting is essential for cloud native systems. Without alerts, you don't get notified of incidents, which in the worst case means that companies don't know that there have been problems.

Recommended Technology: [Prometheus Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/)\
Alternative Technology: [Grafana Alerts](https://grafana.com/docs/grafana/latest/alerting/)

### 12\. Tracing

Cloud native technologies reduce the overhead in launching and scaling services. As a result, teams often launch more services than they did pre-cloud. [Tracing enables teams](https://opentracing.io/docs/overview/what-is-tracing/) to monitor communication *between* services and makes it easy to visualize an entire end-user transaction and each stage in that transaction. When performance issues arise, teams can see what service errors are occurring and how long each phase of the transaction is taking. Tracing is a next level observation and debugging tool that can significantly reduce downtime by allowing teams to debug issues faster.

Recommended Technology: [Jaeger](https://www.jaegertracing.io/)\
Alternative Technology: [Zipkin](https://zipkin.io/)

### 13\. Service Mesh

[Service meshes](https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh) are the Swiss army knife of cloud networking. They can provide dynamic routing, load balancing, service discovery, networking policies, and resiliency primitives such as [circuit breakers](https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker), [retries](https://docs.microsoft.com/en-us/azure/architecture/patterns/retry), and deadlines. Service meshes are an evolution in load balancing for cloud native architectures.

Recommended Technology: [Istio](https://istio.io/)\
Alternative Technology: [Consul](https://www.consul.io/)

Stay Competitive With Cloud Native
----------------------------------

Cloud native tools help companies stay competitive by increasing both quality and availability while decreasing time to market. 

Companies that choose the right tools can maintain competitive advantages through increased delivery speed and agility. 

Adopting cloud native technologies may seem daunting, but just remember that beginning with a single technology can already provide considerable benefits.

About me, Kentaro Wakayama
--------------------------

Kentaro is CEO and Solutions Architect at Coder Society. With his in-depth knowledge of software development and cloud technologies, Kentaro often takes on the lead engineer's role. His analytical, organized, and people-oriented nature makes him an apt advisor on software projects and flexible staffing.

About Coder Society
-------------------

We are a network of 150+ tech freelancers developing custom software solutions for leading companies on-site and remotely.

If you need help getting started with your cloud native journey, [check out what we can do](https://codersociety.com/).