The Amazon Web Services console isn’t extensible in the way conventional management consoles are. Asgard (a Netflix open source project) may provide an extensible open source alternative.

Generally speaking, the Amazon Web Services (AWS) console lags behind the features that are available in the platform and exposed by the application programming interface (API). This has led to a widespread use of scripts and other tooling. Whilst there are specialist consoles from which to manage AWS—RightScale and Ylastic, amongst others—there is a more general problem of third-party tooling that requires some AWS API features to function.

For example, the tool may need to start an instance. It can query AWS using its API to find the available instances and offer them in a dropdown to the user. However, what happens if the instance doesn’t exist? How can the user create the instance? There seem to be two options:

  • The user has to go into the AWS console and create the instance—hardly a seamless user experience.
  • The tool replicates the ability to set up and configure instances.

The problem with replicating features is where to stop adding them.

In most other management consoles—e.g., Microsoft Management Console (MMC) and vSphere—there is a plugin architecture (referred to as snap-in in the case of MMC) that allows you to add features to the console inside the same user interface within which the standard features are present, so that you don’t have to use two tools. The AWS console doesn’t have this.

The question of credentials is also quite interesting. In vSphere and MMC, the plugin operates in the same security context as the console itself, which means it doesn’t have to separately authenticate its access to the APIs to the underlying platform. In the case of AWS, your tooling is using the API outside the console’s security context, and so it needs to supply credentials to AWS. There is no particularly sensible way of storing these credentials in your application, because the password needs to be decoded before it is sent into AWS. The best solution seems to be to authenticate both your application and AWS using OAuth or OpenID, but this requires some setup inside AWS.

However, you are left with the problem of embedding your tool functionality into something that has all of the other capabilities to manage AWS without writing all of that functionality yourself. It turns out there is an open source project—a fairly hard-to-find project, it must be said—called Asgard (https://github.com/Netflix/asgard), which offers a fully functional AWS interface. It was built by Netflix and is used to manage its AWS estate. The project is active on GitHub, but it doesn’t seem to have a lot of traction in the community. However, it’s written in Groovy/Grails (two technologies I’m familiar with), so I checked it out. Architecturally, it’s quite interesting, providing a variation on a standard Grails Model View Controller (MVC) architecture in which, instead of the model being persisted in the usual way via Hibernate, the controllers speak to Grails services, which mediate the AWS API.

So, does Asgard provide what we are looking for, an extensible tool that we can use to control AWS and also to embed our own functionality into?

Well, not really. The problem is that Asgard doesn’t provide extension points. It’s standalone, so if we change it, we are effectively forking the codebase, and that doesn’t seem like it’s a good thing to do. That said, Grails has its own extensibility mechanisms, so with a little refactoring it might be possible to repackage it as a Grails plugin, which we could incorporate into our tool.

More generally, however, it would help the AWS tools marketplace if Amazon itself considered providing some sort of open source console with extensibililty, either by making its own console open source or by supporting Asgard. That would then allow a community of tools builders to come together, focusing on a single integration platform and providing a coordinated experience to users.