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.
When, What, and How?
- As of Monday, Aug 10th, 20:00 UTC you will no longer be able to create applications in the old format. All applications created after that should already be defined according to the revised format.
- A few hours later, on Tuesday, Aug 11th, 07:00 UTC we will release the new CLI and a major documentation update to reflect all changes that come with this revision.
- Any application you have created in your organizations and environments will be migrated by us for you in time to be running on the new release.
- You will have to update your CLI to the latest version on (or after) the 11th of August in order to be able to interact with your services, though. You can get the service definition of your migrated services with
swarm cat then. To get your local files updated you can use the new swarm migrate command.
What Has Changed?
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.
Only services and components
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 service and 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.
Linking independent services
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.
Components without images
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.
Why Should I Care?
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.
Why Did You Do That?
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:
- Flexibility: Define simple and complex services.
- Simplicity: Focus on the components and attributes of a service and remove boilerplate.
- Modularity: Assemble several definitions from different locations / repositories.
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.
No Comments Yet
Let us know what you think