Wavefront

Back in 2017, VMware acquired Wavefront – a company based in the US which focuses predominantly on real-time metrics and monitoring of a really…really vast array of platforms and technologies. We have technologies that aid in adopting and promoting cloud-native implementations, but monitoring, in some peoples eyes, can be a bit of an afterthought. Wavefront to the rescue. Having developed some Kubernetes and Docker knowledge myself, it seemed rather fitting to get an example going.

GCP – Creating our Kubernetes cluster

To begin with, we need a Google Cloud project. Log into your GCP account and create one:

Access the Kubernetes Engine:

You may have to wait a few minutes for the Kubernetees engine to initialise. Once initialised, create a new Kubernetes cluster:

We have a number of options to define when we create a new Kubernetes cluster:

Note: You are not charged for, or responsible for deploying and maintaining the master nodes. As this is a hosted solution, Google takes care of this for us. As for the cluster options, we have the following base options to get us up and running, all of which should be pretty self-explanatory.

Name – The name for the cluster.
Description – Optional value.
Location – Determines whether our cluster’s master VMs are localised within a single zone or spread across multiple zones in one region.
Zone/Region – Determines where our clusters worker VM’s are localised.
Cluster Version – The version of Kubernetes to be deployed in this cluster.
Node Image – We have two choices, either Container-Optimised OS (cos) or Ubuntu.
Size – Number of nodes in our cluster

One aspect of this wizard I really like is the ability to extract the corresponding REST or CLI command to create the Kubernetes cluster based on the options selected:

Click “Create” to initialise the Kuberntes cluster.

GCP – Deploying a simple application

After waiting a few minutes our Kuberntes cluster has been created:

To connect to it, we can click the “Connect” button which will give us two options:

At this stage, you can deploy your own application, but for me, I deployed a simple application following the instructions located at https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app

Wavefront and Kubernetes integration

To get started, we need to deploy the following:

• Wavefront Proxy
• Wavefront Proxy Service
• Heapster (Collector Agent)

The YAML files are located at the following URL : https://longboard.wavefront.com/integration/kubernetes/setup

Note that you’ll need a logon to access the above URL. Also, and very cleverly, the generated YAML files contain tokens specific to your account. Therefore, after deploying the YAML files Wavefront will automagically start collecting stats:

Thoughts on wavefront

Once I got everything up and running I was pretty much in awe of the sheer depth of what Wavefront has visibility of.  From my tiny, insignificant environment I’m able to get extremely detailed metrics and content pertaining to:

• Clusters
• Namespaces
• Nodes
• Pods
• Pod Containers

In particular, I was very impressed as to how easy it is to get wavefront to ingest data from the likes of GCP hosted K8s.

Post-AWS Summit 2018 Thoughts on Serverless and Containers

I was lucky enough to attend the AWS summit in London in May 2018. It was a first for me,  and the experience was pretty awesome. With a veritable smorgasbord of chalk talks, instructor-led demos and vendor presence there was something for everyone. I gravitated towards the docker/lambda sessions as I had recently picked up learning container technology, which got me thinking – from my perspective (previous ops-centric), how does container technology compare to the likes of serverless? When would you use one over the other? Whilst on the train home from London I decided to jot down my notes into this post.

Primer

I’m not a dev, but I have some development background. I got acquainted with C# in the past and wrote a number of applications – probably the most complicated one I wrote was a remote data collector for Windows-based machines to extract data from the WMI (Windows Management Instrumentation)  database, and then present this is an ASP.net page. But I’m fully aware things have moved on a lot since then. My career history has predominantly been based on the design, implementation and monitoring of infrastructure.

What I like about containers

• Flexibility – You can pretty much take any existing application and package it into a container image. At this point, it’s portable, lightweight and may not require any change to the app itself.
• Control – You have extensive control over the platform in which your containers are running, as well as the runtime itself.
• Scale – Container environment can scale tremendously well and cater for the complete n-tier architecture.
• Self-Contained – Excuse the pun, but you can encapsulate an application, its microservices, and it’s dependencies within a single ecosystem.
• No Vendor Lock-in – Don’t like a particular way a cloud provider is hosting your containers? Simply move them elsewhere.

What I don’t like about containers

• Can be complex – Orchestration tools such as Kubernetes can generate a bit of a learning curve, especially for non-devs.
• Requires a change in mindset – Containers should be short-lived and ephemeral – treat them like cattle, not pets. Those who are used to nurturing, patching and tweaking individual VM’s will experience a bit of a mindset change.
• Microsoft has some catching up to do – The smallest Linux container image is a few MB, whereas the smallest Windows image is a cool 1GB or more.

What I like about serverless

• Abstraction – Zero touch on the infrastructure or runtime.
• Cost – Can be significantly cheaper than running applications/services within VM’s.
• Auto Scale – Increase resources with demand, scale back when not required.
• Quicker time to deployment – Implement services quickly and efficiently.

What I don’t like about serverless

• At the mercy of the provider – For example, with Lambda you’re at their mercy when it comes to changes or outages with the service.
• Runtime Limits – A Lambda function can have a maximum lifetime of 5 minutes,  Minimum = 128 MB / Maximum = 3008 MB memory and 512MB of ephemeral disk space. This means that particular functions that are CPU intensive may not be well suited.
• Language Limits – You are limited to writing code for specific runtimes supported by Lambda. For example, The latest version of Node.js that’s supported is 8.10, whereas newer versions have been released. To take advantage of additional features or bug fixes, you have to wait for the provider (AWS in this case) to update accordingly.
• Latency – Expect invocation latency for functions that have not been executed for a while. This can yield unpredictable time to execute. Therefore, if you have services that are latency-sensitive, serverless may not be the best option.
• The name – “Serverless” is not server-less. It runs on servers, including containers (!). Personally, I find the naming a misnomer.

So, which one is “better”?

I’ve read a lot of blog posts that compare the two – personally, I don’t think they can be compared. There are workloads you can do in containers but not in serverless and vice-versa – they solve different issues and have their own advantages and disadvantages. The deciding factor between them has to be influenced by exactly what you need to do/run. Ultimately though, from my perspective it boils down to whether or not you need to have absolute control and access over the runtime environment – If you don’t, serverless technologies from the likes of Lambda are great. If you need greater control and visibility of how & where and in what language/compiler you want your code to run in/from, containers may be better.

Container ecosystems can be pretty self-encapsulated. Lambda, however, works best by acting as a “glue” to bring together other features and resources from the AWS ecosystem into the bigger picture.

It’s probably worth mentioning that when you invoke a Lambda function, behind the scenes a container is spun up to execute your code, adding further weight to the reasoning behind not doing a direct comparison. Lambda actually needs containers to run.