Lagoon 2.0 Vision – What We’re Working On

Back in our Lagoon 2020 Roadmap we discussed the work being undertaken to bring Lagoon to Kubernetes, and in Lagoon 1.4.0 (in April) we introduced the ability to run Lagoon workloads (projects/sites) on managed Kubernetes clusters.

We’ve also variously discussed some of the aspects of what Lagoon 2.0 will bring; in our webinars, posts about managed Kubernetes, and even our migration process. All the time, the team has been hard at work continuing to deliver features for Lagoon 1.0 - bringing heaps of new functionality, improved performance and better security.

We have always had one eye on the future though, and the whole team has been hard at work trying to decide what Lagoon 2.0 should look like. As I’ve discussed at a couple of our Office Hour sessions, we elected to not use the major version designator when we released Kubernetes deploy functionality (as it technically didn’t break anything existing), and instead decided to work towards full Kubernetes support for 2.0.

In a recent team session, we covered what is actually needed for full Kubernetes support. Thankfully most of the new features delivered in the last six months are also (by design) compatible with Kubernetes as well as Openshift 3.11, which will reduce the amount of work needed to bring full compatibility.

In our discussions, we’ve identified the following areas that need re-working for Kubernetes:

• All current Lagoon-internal services will need to be reimplemented as Helm Charts
• Wherever possible, any service that re-implements an upstream service should utilise any Helm Charts (or Operators) that are provided by the upstream project
• The API will need to be modified to support the concept of “Deployment Targets” to better define the configuration of a Cluster, and also remove any hardcoded variables for Openshift
• We can also deprecate a couple of GraphQL mutations that are no longer required.
• Lagoon should be deployable from scratch (it currently requires an existing Lagoon to deploy it) – this would also better allow per-cluster configuration and specification
• We’ll also be looking to simplify the Lagoon project structure, grouping and separating services as required, all to make things easier to understand

What will this mean for you?

As a user: Hopefully nothing! As most of the Lagoon 2.0 work is being done behind the scenes, it is our responsibility to ensure that we impact existing projects as little as possible. As we currently see it, there should be no changes required to existing client-side project configurations. However, as outlined when we discussed Managed Kubernetes, there will be a wealth of options when it comes to configuring dedicated amazee.io hosting options - you will be able to choose from more cloud providers across more geographic locations.

As a developer for a site: Same as for users, we would expect no changes to your current workflow, project configuration or experience – there may be some new API functionality available to you, but most of the deprecations we’re looking at are targeted more at the admin level. As we make the changes, we’ll also have to make some modifications to the lagoon-cli tool at the same time.

As a platform owner or project manager: Having more choice about the underlying hosting solution for Lagoon will obviously benefit customers with existing infrastructure portfolios or preferences, and being able to leverage more best-practice Kubernetes architectures will reduce complexity.

As a Lagoon contributor: We have always known that Lagoon is hard to contribute to - the configuration of the project, the system requirements for local development, and the level of customization can be hard barriers to overcome. With a move to a more standard Kubernetes setup, we should be able to provide a smoother on-ramp for new developers, a better ecosystem to contribute around, as well as requiring significantly less local resources (no more 8+GB minishift running!). We’re also using this as an opportunity to perhaps streamline what is needed to build Lagoon in various scenarios (local, CI, “core Lagoon” or remote).

Over the coming weeks, we’ll hold a couple more Office Hours sessions to discuss the work we’re undertaking on Lagoon 2.0, where we’re up to, and what this all means. Keep an eye out here, or on our various social media feeds for the details. You can also get in touch with us anytime.