Cloud native technology and Kubernetes focus on conference agenda
On March 28-30, I attended the CloudNativeCon + KubeCon Europe 2017 in Berlin together with some colleagues. The conference is arranged twice per year, once in the US and once in Europe, by CNCF (the Cloud Native Computing Foundation); a nonprofit organization committed to advancing the development of cloud native technology.
A massive technology shift is about to happen
Already an advocate of containers and cloud-native technology, I had a pretty good grip of most of these projects. However, I did not have any idea how strong the cloud-native community is. I also could not fathom the amount of companies investing in this – both in using the technology, and furthering it. I knew it was a big deal in the US, but also in Germany and Europe in general, cloud-native is emerging as an entirely new business area.
This is a massive technology shift waiting to happen. Central to this shift are containers, microservices and the new kid on the block: Kubernetes. In many ways, this was a confirmation for me – our thoughts and ideas are on the right track.
“I knew it was a big deal in the US, but also in Germany and Europe in general, cloud-native is emerging as an entirely new business area.”
Development speed gives competitive edge
A recurring theme kept popping up during the conference: development speed. This is something that everyone ought to be excited about. Why? Because it is probably the most effective way to get an edge over your competitors.
Development speed will not only let you deliver more features in a shorter time; it will give you the time to improve your user interface, and to address critical stability and security upgrades. I heard speed mentioned by no less than 8 companies as either the main driver or a key takeaway from their cloud native transformation.
This is interesting, since it is something that we at Pagero try to address daily. We are continuously working with questions such as:
- How can we increase stability and minimize maintenance?
- How do we decrease recovery time in case of critical failure?
- How do we introduce more effective automation of processes?
- How can we increase team output (in terms of effects, not deliverables)?
- How do we enforce security without introducing a barrier for the users?
For me, a key takeaway from the conference is that the cloud-native technology can help you here. Most of these projects are designed for security, high availability, scale and automation. For a project like Kubernetes, a key principle is to minimize the infrastructure bootstrapping required from developers before they can start to deliver product features.
They can also help you increase team autonomy, which will in turn let you ship more – and better – functionality to your customers. Features like the dynamic routing in linkerd will help you test your changes on a few customers – and get feedback – before releasing them. The possible benefits of this are larger than you might first anticipate. For example, during his talk What is Cloud Native and Why Should I Care, Alexis Richardson discussed recovery time in case of a software bug.
According to The state of Devops survey from 2015, by Puppet Labs, the fastest companies had a mean recovery time 168 times faster than the slowest. What one company could resolve in 1 hour, might take another company 1 week.
You do not want to be on the wrong end of that scale.
Special Interest Groups – collaboration for fast improvement
While we are on the topic of autonomy; I was really intrigued by how the Kubernetes community works with SIG:s (Special Interest Groups).
These are groups representing different companies and individuals with a special interest in a specific area; for example SIG Testing lead by Google and Samsung, or SIG Apps, headed by Deis & HPE. Each of these groups have the mandate to make decisions affecting their own interest area.
Although these companies can be competitors, they have a mutual interest in the improvement of Kubernetes. This is a key strength of the project; this diversity of perspective allows ideas and solutions to be thoroughly, and objectively sounded.
I cannot help but to imagine what we could do with that level of collaboration on the local scene here in Gothenburg. There are a lof ot technology companies here that are not competitors, and would be perfectly free to collaborate on things like infrastructure, software, and sharing of resources.
Internal SIG:s are something that I think would make a very good addition to our own organization; and we’re probably borrowing this term and concept.
“For a project like Kubernetes, a key principle is to minimize the infrastructure bootstrapping required from developers before they can start to deliver product features.”
There were loads of interesting talks and presentations on the agenda, and I strongly recommend taking a look at the Youtube playlist; but I want to share some glimpses of what appealed most to me.
Scaling organisations with Kubernetes – Richard Fliam, Comcast VIPER
This talk was a great sanity check for me. I have spent an insane amount of time considering the best practices and pitfalls of scaling teams and organisations. Richard provided some very real experiences from an incredible success story.
This talk did not introduce a lot of new concepts, really, but it strongly resonated with my thoughts on organizational scalability, team autonomy and using technology as a catalyst for organizational change. If your teams are constantly getting stuck on ops lock-in, you really should consider a different approach to infrastructure.
Go + microservices = Go kit – Peter Bourgon, Fastly
Microservices are not news to me; I have been sold on the concept before it got that name and by now, I have written a few. There are several reasons why I think golang is a great match for microservices, and Peter Bourgon brought up some of them.
We also got some history on golang & microservices; a presentation of the go-kit architectural choices and a list of alternative frameworks. Peter does not so much try to push his own framework as the concept of writing microservices in go.
I was pretty much sold on the practice beforehand, but I liked the level of detail, the speed and the clarity, and – judging by the amount of applause – so did everyone else.
So, are we writing golang microservices in Pagero? Not really – but we have recently started on our first.
Building a cloud-native SQL database – Alex Robinson, Cockroach Labs
Alex Robinson was very knowledgeable, not only about Cockroach, but database design in general, and a great speaker.
His talk was on the technical track and we got a deep dive into how Cockroach has been built, challenges and how they were solved. This was interesting not only from a database perspective, but also something to consider when building distributed applications.
I am fairly well-versed in databases and today, there is a lot to choose from. Still, I think the wire-compatibility with PostgreSQL is a really interesting feature. However, keep in mind that not all PostgreSQL features are yet supported – or probably likely to be.
We use Postgres for our products, so we will keep any eye on Cockroach. But we are not quite ready to invest time in it just yet.
“There are several reasons why I think golang is a great match for microservices, and Peter Bourgon brought up some of them.”
Miscellaneous news and impressions
Here is a short recap on some other news and impressions that I thought might be valuable to share with you for inspiration.
The Torus project, by CoreOS was cancelled in February. To me, the most interesting alternatives at the moment are Rook; a Kubernetes-native Ceph implementation, and Minio; an S3 compatible solution for distributed storage. Both of these are open source. OpenShift are still sticking with GlusterFS for now, but it looks like they’ll go with Ceph in their next major release.
At the moment, Helm by Deis seems to emerge as the defacto standard for packaging applications for Kubernetes. I cannot help wondering how Microsoft’s move to purchase Deis will affect this development.
On Matchbox / Tectonic Installer
Matchbox, which is a solution that allows you to quite easily IPXE boot a Kubernetes cluster, seems to slowly be gaining traction. This could be a very powerful way to bootstrap your clusters. Also, CoreOS Tectonic has a graphical installer that produces output to Matchbox.
The conference was a really valuable experience. I was able to confirm that many of our thoughts and theories are likely to be effective. I discovered several new software projects that are likely to help us here, and was able to dismiss a few. Overall, the experience was a great inspiration, and I am really eager to put these ideas into action.
See you in Copenhagen, 2018!