BUILD WHAT'S NEXT | A ZDNet Multiplexer Blog What's this?

Order amongst chaos: automation best practice in a serverless world

Without straying too far into any notion of 'cookie cutter' computing, how intelligently can we apply custom-built pre-templated automation controls into serverless environments based upon defined (and agreed) best practices for information management and application deployment?

As we have said before, moving to architect our software applications to the new mantra of serverless gives us the opportunity to create stateless applications that run on event-based architectures.

The very nature of stateless allows us to build an application that has an inherent appreciation for its own dynamic nature. The application knows that its requirements for backend resources is changeable depending on user behavior and the wider need for system-based analytics and other extended functions.

Once we start to build software that more directly knows its rate of resource requirements is inherently changeable, then we can structure our architecture to be more sympathetic to the total universe of applications and services that exist inside any given IT stack.

Order amongst the chaos

If we shoulder this core understanding of (and appreciation for) the fact that our application's event-based requirements are dynamic, we can then stand back and start to bring order to what initially looks somewhat like a world of variability and chaos.

If we build our applications with a more intelligently holistic appreciation for their environment, then we can start to craft custom-built pre-templated automation controls into these serverless environments based upon defined (and agreed) best practices for information management and application execution.

Creating these 'custom-built pre-templated automation controls' is complex, but if we know where to look for the data sources that can help build them then the task is more straightforward, if still complex at the higher level.

Layers of automation

A simple form-based web application (for example) such as an application form app will experience spikes in usage based on seasonal trends, time of day and special offers. This means we can automate to allocate a predefined amount of system resources to it based upon the observed cyclicality.

We can also leverage a degree of automation advantage from 'crowdsourced' data. Not literally from the crowd or the general public, but from a collated group of other use cases where any Intellectual Property or personal information is appropriately anonymized and obfuscated.

Further still, we can apply a degree of application automation based upon the 'nature' of the application itself. A desktop application would typically only have to work for one user, need access to one (or a limited number of) file systems and work with a defined amount of memory. This means that the application itself is essentially 'stateful' and so we can automate system resources to provide it with what it needs to execute.

Taking that desktop application to the web and making it essentially stateless means that we need to architect for a different landscape.

Living online and in the cloud, that same application might be being used by a number of concurrent users, require access to a wider number of file systems across a distributed infrastructure and have to shoulder many more complexities (such as device form factor compatibility and whether or not it needs to be able to work offline). Automation in this scenario is therefore more complex, but it is still possible if we are able to track and map typical use case patterns driven by user requirements.

Automated, by nature

Automation efficiency in serverless environments has an inherent degree of complexity, but serverless applications have automation in their DNA at the build-to-deploy stage, so we should be looking to create higher-tier layers of automation at the execution layer.

As we architect and build applications with automation efficiency in any environment (serverless or not), there will always be a large amount of verification and testing that needs to be performed throughout. In a world where Continuous Integration (CI) and Continuous Deployment (CD) have become the norm for always-on web and cloud, this is not an insurmountable challenge.

Finally, it's important to remember that things could get tougher before they get easier. As developers start to use so-called 'polyglot programming' techniques that bring together code streams developed in more than one language, we typically see resource consumption increase not decrease.

We can still embrace automation in complex serverless environments, but we should do so with a calm, Zen-like approach and build the wall one brick at a time.