The Drupal ACT meetup happened last night, and the combined team at Finance/Salsa Digital/Amazee IO presented a very in-depth look at the new GovCMS which is due for launch in November - hopes for a live demo at DrupalSouth were discussed. I was involved in Salsa's previously successful bid to build SDP for Dept of Premier & Cabinet Vic.), so I'm very very interested to see how GovCMS is progressing. Here is my summary of the parts that interest me:

The distribution

We didn't see much of the distribution last night, but if you weren't aware, the GovCMS Drupal 8 distribution is already a proven entity. Lil Engine helped to build Scaling Frontier Innovation with Today on GovCMS 8 and it needed the barest tweaks to deliver it.

I can be very critical of Drupal distributions, which are often very opinionated, and should better be referred to as "templates". But GovCMS 8 is very fit-for-purpose. It is a solution that works great for many government websites, and there are only a few situations where it would be a poor match (headless is one example in my opinion).

Config in the repo

I'm a fan of .barely-hidden-config.yml configuration for hosting. It's something that Platform.sh does very well where, even if you don't know much about containers, your platform configuration is surfaced into your project. It gives you this sense of "Everything I need to build this site is defined in my repository".

Configuration for GovCMS is very akin to Platform.sh in this way. It's mostly a collection of Docker config and everything feels "native" Docker. The docker configuration in the repository is very sparse because all the heavy lifting is in the upstream containers, but it means that even on the SaaS service, you'll be able to add additional tools and configuration locally (even if on SaaS you won't push these changes to production.

This architecture should encourage developers to solve their own problems in the short term, and become contributors to GovCMS later. It is I believe a perfect level of control that assumes that if you start tinkering with these files, you're probably solving a problem that should later be applied upstream. There is incentive for people to learn Docker, and apply this learning to other projects.

Dev containers

There is a very clear intention to solve local development issues by providing containers with baked-in tools. When you docker up locally, you'll get a container that containers Behat, PHPUnit and other dev tools ready to go.

A fascinating example is having an Gitlab Web IDE built into the container (correction from Alex, it sits in the cloud with Gitlab). It almost harks back to when Drupal sites were hacked together using cPanel text editors (yes it happens) but in a good way, and with the full CI suite ready to go on top.

It makes me wonder whether these dev containers will be usable for non-GovCMS projects. If a vendor does 90% GovCMS, how hard will it be for them to retain a consistent developer workflow on other projects by forking the dev container upstream? With the existing user base of GovCMS driving improvements in the GovCMS tooling, will GovCMS solutions be borrowed for other workflows? Would we see a Drupal community code sprint using GovCMS tools which have been forked to use vanilla Drupal core? 

Workflows and Ahoy

It was interesting to see that the .ahoy.yml is just a set of command shortcuts, similar to your scripts section of a composer.json. This lays the groundwork for the GovCMS team to solve developer issues in systematic ways — awkward implementation can be smoothed over by a single Ahoy command, and the underlying implementation can evolve without the developer even noticing.

Speculating, I think the hardest part about adding Ahoy commands will be naming them. Even then, the GovCMS team will have the luxury of focussing on the "SaaS govcms 8 on Lagoon" use case, rather than something like BLT which attempts to have commands for "any drupal anywhere".

Much open source

Tthe Lagoon product does push us to the very limits of what can be realistically open sourced and free of vendor lock-in. So what would it take a government organisation to run/roll their own Lagoon? 

• You will need bare metal provider. It's going to be AWS, Azure or Google cloud, but you don't need any consultants for these platforms - you are consuming container services only.
• You need OpenShift* (beefed up Kubernetes), which means you need Redhat for support of their baby. You're gonna pay a pretty penny for this top-level support, but then suddenly you can run almost any service (any containers you already deem secure) securely in the cloud.
• You need Amazee*, OR you'll need some very very smart devops people who can immerse themselves in Lagoon, and track the shifting, changing landscape that is a dozens of microservices that comprise Lagoon working together and evolving independently.

(*) Technically you don't need any of these things, but from a practical perspective few organisations have the depth of talent to run the necessary tools in parallel. 

I predict that Amazee will have competition in 2019. Other providers who will sell Lagoon implementation and support on OpenShift. And I guarantee that Amazee look forward to the pull requests!

End user dashboards

OpenShift is pretty sexy, we saw pods coming up and down in response to PRs and dashboard changes. We saw log information coming directly from containers. We saw performance graphs. It's sleek and mature.

But OpenShift is an internal tools for running the platform - there is no intention for the Dept of Small Things to log into OpenShift and see a keyhole or aggregated view of www.smallthings.gov.au. 

Something that we struggled with on Lagoon in the past was getting enough meaningful information from containers when something is going wrong. Last night I heard the magic words "'As a user I want to see my logs' is down there somewhere in the backlog". And the team spoke about simplified dashboards outside of OpenShift.

The roadmap for these features seems tied to Helm and Grafana, and getting the security right will be critical. I suspect these features will be accelerated (and sometimes delayed) by the evolution of these tools in the Kubernetes community at large. It's a bit of "watch this space".

Conclusion

Just scraping the surface of GovCMS on Lagoon, I think it will be disruptive. We will see a lot of innovation flow back into other Lagoon projects like SDP, we will see new Lagoon setups in other areas of government in Australia, it will give unprecedented control over the cost-of-ownership (hosting costs) for Finance, and it will be a compelling story for open source in general. Congrats and god speed to everyone involved!