Don't Wait To Be Cloud Native To Be Cloud Native!
To be, or not to be... is not really a question in my mind. Today is the day that your enterprise should begin to leverage Cloud Native!
But you're much too busy getting behind in your capacity, provisioning and deploying your infrastructure and software to integrate a major change like Cloud Native. Maybe you've been waiting for the revolution to take over your business. Maybe It's going to be hard and it's going to be expensive, you say.
Wrong... and you don't even have to wait for DevOps to happen to take advantage of the cloud native tools being developed today.
Why should I?
- Business is up and you can't keep up, even with the addition of the public cloud
- Customers are demanding stability
- GDPR!
- Snowflakes, snowflakes, snowflakes
So, how is this possible?
If you give up defining Cloud Native as a completely containerized pipeline from desktop to deployment, it begins to sound easier. It really is tough to plan, train and implement things like containerization for a large organization, but software providers and open source projects have embraced containerization while you've been struggling. Many, if not all of your dependent middleware and metrics solutions come in a containerized flavor. In addition to this, interest in microservices and containers have inspired the creation of many new products and open source projects that satisfy an enterprise's software and infrastructure needs.
You could continue to go through the process of building systemd units with a lot of complicated scripting to install each of the services that you need on your servers. This typically requires a lot of work and a lot of custom code. The result is that it makes it too easy to prioritize other work, makes proliferation of snowflakes inevitable, makes it hard to track what you have deployed and opens your organization up to security events.
On the other hand, containerized versions of the same services offer a number of advantages:
- They're bundled with all of their dependencies
- They are straightforward to configure and start in a way that creates uniformity of code across service units
- They are versioned and easily rolled forward or back from a central repository. This greatly improves an organization's ability to rapidly address CVEs, or upgrade to new versions.
- They offer a consistent interface for logging and monitoring
- They offer a consistent interface to managing resources like cpu, memory and network on a per container basis. This way you can guarantee that your log forwarder isn't going to overwhelm your cpu or your network throughput.
.. but don't I need Kubernetes
I'd like to say yes, but this just isn't true. Kubernetes is now out of incubation and ready for enterprise, but it does require an all-in approach to containerization for anything you want to deploy to it. Without Kubernetes, DCOS, or Docker Swarm, you don't have an orchestration tool, but that's not the problem we're trying to solve here.
If your organization is in the not-yet stage of container delivery for your enterprise software, you can still take advantages of containerization; this approach is do-able for just about any organization. You only need to byte off what you can, when you can. Before too long, you'll start getting your server configuration and automation under control with fewer snowflakes and greater manageability.
What can I start with?
The following is a far from complete list of tools to give you a sense of what's available:
- Networking: NGINX, Ambassador, Project Calico, Linkerd, Traefik
- Tracing and Application Monitoring: New Relic, Sysdig, Jaeger
- Logging and Monitoring: Splunk, Fluentd, LogStash, ElasticSearch, Prometheus, Grafana, Kibana
- Caching and Middleware: Redis, Memcached, RabbitMQ, Kafka
- CICD Tools: Jenkins, GitLab, GoCD, Artifactory, Consul
- Database: Oracle, MySQL, MariaDB, MongoDB
You get the idea...
