• Aug 7, 2015
We’re moving to a new format for defining services on Giant Swarm. In this blog post we want to explain to you the migration timeline, main changes, benefits you will experience as well as reasons behind this revision.
swarm catthen. To get your local files updated you can use the new
As those of you that have read our documentation or technical blog posts, tried Giant Swarm, or even have a dedicated cluster know, developers use a simple JSON file (usually) called
swarm.json to set up and create their applications on the swarm. This process generally won’t change with this revision. What will be changing, however, is the format and expected contents of said definition file.
First, we are simplifying the nomenclature, while opening it up to be more flexible. Until now you were forced to use a strict hierarchy of
application/service/component. With the new definition format you will only need to use
component, where each definition file, i.e.
swarm.json, represents only one service. Under this service you can have as many components as you like. Each of these components then can have sub-components, which can again have sub-components of their own.
If you want, you could build this out into a very deep tree hierarchy, which at some point, however, would get confusing. Thus, now services will be able to communicate between each other. That is, you can now define completely independent services in independent definition files and then link them together without having to go through external domains.
Another change is that now you can have components that do not provide a Docker image to be run. These components can be considered configuration components, which for example can be used for scaling or grouping.
Grouping components into pods has been available to our users since our last CLI release in June. With the new definition format the pod functionality basically stays the same, however, its usage will change. Pods are now defined by the component hierarchy that you build into your service. That is you can group all children of a component into a pod or go even further and recursively include all children and the children’s children. Additionally, for edge cases, you can exclude single components from a pod.
As already mentioned a bit above, these changes bring with them quite some benefits in form of flexibility and power of your interface to Giant Swarm.
This includes that through the new service & component(s) structure, you have the freedom of choosing your own grouping and hierarchies as deep or as shallow as you feel like it.
On top of that the new ability to link independent services enables you to update your application consisting of different services more flexibly and enables changing of services without having to restart the whole application. Further, it enables some use cases that were not possible before and which we will be exploring in further blog posts and/or guides in the documentation.
Last but not least, the ability to define components without an image can be used to flexibly group, scale, and configure not only single but groups of components incl. sub-components.
When working with a microservice architecture, the way you define services is essential. A developer spends a great time with this definition constructing their service, changing and updating it, and most importantly reading and maintaining existing definitions. Therefore, we at Giant Swarm spend a great deal of our time getting this interface right and are constantly learning with our users to improve on it.
Together with our early customers we found that, especially when you want to work on more complex applications, there are several issues with the current definition format. Thus, we sat down and thought about, how we can improve the interface to make it easier to work with as well as satisfy our users’ needs.
After some thinking, we came to three major design goals of this new version that especially come into play when moving from simple applications to more complex (microservice) ones:
The result of this design process was a bigger revision of what we were calling application configuration or for practical reason just
swarm.json. Keep in mind that this revision, while it deserves to be called major, still has room for improvement. However, it already comes prepared for a lot of upcoming features that will make working with Giant Swarm even more powerful while keeping or even improving the flexibility.
If you have any more questions as to implications or other things related to this revision, feel free to comment below or contact us on any of the known channels.
Giant Swarm’s managed microservices infrastructure enables enterprises to run agile, resilient, distributed systems at scale, while removing the tasks related to managing the complex underlying infrastructure.
GET IN TOUCH
CERTIFIED SERVICE PROVIDER