By Kelly Tenn, August 24, 2015
Originally published on the CoreOS blog (archived copy) . Re-published with the authors' permission.
Timo Derstappen (@teemow), co-founder from Giant Swarm has joined us for various events in the past, but you may recall seeing his talk at CoreOS Fest this year (embedded below). We sat down with him to see what Giant Swarm is up to and how Giant Swarm uses CoreOS for their microservice infrastructure.
Q1. Explain what Giant Swarm delivers and what inspired you to co-found the company.
A: Giant Swarm is a Microservice Infrastructure. Given the fact that the term Microservices is used by a lot of people lately, I’m going to explain this a little bit more.
At my last company we grew pretty quickly and after a rush of feature implementations we stood there with a monolithic app that now had to be scaled. We looked closely at the different requirements within the stack and decided that we would prefer to choose the right tool for each job. This was the complete opposite to what we did before, where we had one techstack and tried to solve everything with it. By isolating problems in small services we were able to scale in many dimensions. Teams weren’t blocking each other, services could be scaled independently, and we iterated faster. It was also very expensive in terms of automating the infrastructure to run the zoo of technologies we were suddenly using. 20-30% of the developers were always blocked by automating the infrastructure. After leaving the company we took some time off and I worked on a next generation platform I wanted to use for our next idea. Wherever I demoed that, people either wanted to have that too or work at our company.
So the infrastructure itself became the next idea. We now run that infrastructure for many developers, first customers are going into production with their own dedicated clusters, and we now also offer on-prem installations.
Q2. How does Giant Swarm fit into the world of distributed systems and containers?
A: Giant Swarm builds a layer on top of containers and enables developers to declare and manage their microservices without thinking about servers. We map their software architecture onto a container infrastructure distributed across many servers. Our product clearly addresses developers. We enable them to actually live up to “You build it, you run it” without the hassle to actually learn how to setup a production ready container infrastructure with networking and storage solutions that fit in such a highly dynamic environment.
Q3. Your talk at CoreOS Fest on Containers on the Autobahn discussed what fast means in the world of containers and distributed systems. Explain what is most important to do when looking to develop and deploy application containers in an efficient and fast way.
A: In my talk I actually not only showed how our users can run their services on our platform, but I also showed how we ourselves are dogfooding by running our own services in containers with the same building blocks we are providing our users with. There is a saying that a good manager is a barrier removal professional, and we are thinking the same way about infrastructure. Good infrastructure should allow developers to run at full speed, not being encumbered by roadblocks. For instance, you want to create a new test environment for your service landscape in a couple of seconds instead of waiting for the other team that is currently blocking the test environment.
In general there are many facets of fast, which we are addressing at Giant Swarm. Low latency, Short MTTR, High Throughput. Which leads to another part of the talk. Although Giant Swarm appears to be a PaaS-like solution to start your application in containers with zero-configuration, we provide you with a container infrastructure that is unopinionated. On your own dedicated cluster you can choose if you’d like to run on AWS or bare metal and which networking/storage fits you best. You can run Kubernetes on it, run your own service discovery, continuous integration, monitoring, etc. There is also a benefit that users can share their infrastructure stacks and try out new ones really quickly.
Q4. How does Giant Swarm make use of CoreOS projects, such as CoreOS Linux and rkt, on your microservice infrastructure? Any tips and tricks you’d recommend for others, or areas where readers can get more information?
A: The whole Giant Swarm infrastructure is based on CoreOS. A small stripped down modern Linux with atomic updates was exactly what I was looking for in a production environment. Even better is that CoreOS follows the Unix philosophy and builds small but capable tools. This enables platform builders like us to provide customers with a flexible solution by combining these tools with other building blocks that cater to the customers’ needs. We also excessively use systemd for our container scheduling and management. Something that might be a bit unique to what we do is that we build container “chains” around each application container to keep the configuration out of the actual application container. The concept is similar to pods, but our chains start up in order and you can create blocking dependencies. This uses a distributed lock to wait for a dependency on startup, which allows us to start and stop complex architectures very gracefully.
Currently, we are using Docker containers to not break dev/prod parity for our users, but we very much favor the concept of a container runtime like rkt, based on the same reasons we like the Unix-like approach of CoreOS.
Q5. Designing an application as a series of micro-services has moved from being an emerging technology to an accepted design pattern. Do you have any suggestions on what enterprise organizations can do to speed the adoption of this new pattern?
A: Moving to microservices is not easy and is even harder for a big enterprise with lots of legacy software and more traditional, late adopting technical staff. There are two categories of hurdles to take with microservice architectures.
First are the hurdles that come with any new architectural or software engineering pattern. That includes questions around what actually microservices are, how they should be cut, if they should contain data or not, and all kinds of new ways of thinking that developers might not be used to, yet. However, there’s more and more articles and even books as well as good consultants that help companies understand and move to the microservices way. In the end every enterprise has to design its migration according to its individual needs - for some starting with a monolith and breaking away smaller services might be a good choice, for others the complete rebuild of (parts) of their systems in microservices style. We have seen both with customers going into production.
The second category of hurdles revolves around the (operations) overhead that comes with deploying and managing microservices. Here’s where container technologies, CoreOS, and Giant Swarm come into play as we all are actively working on solutions to make the development and operations part of microservices a simple and hassle free experience. Using tools that make the first steps towards microservices easier for developers as well as operations teams, make it easier to bring the enterprise to this new pattern. These tools should get out of the way of the users and enable them to focus on the actual implementation details of their microservices instead of having to worry about how to run them on different environments.
Thanks to Timo for chatting with us!
Watch his talk that was given at CoreOS Fest this year.