Take a close look at how two different markets are interconnected and thus provide business value. In today’s column, I’ll take a look at the relationship between low code computing and cloud computing.
Low-code tools simplify and speed up the work of professional developers by providing a visual model-driven environment for building applications. The low code level frees developers from most of the burden of integrating hand-coding, security capabilities, and other “service” code, so they can focus on more important tasks that focus on business needs.
Cloud computing extends cloud computing best practices to all enterprise IT, including horizontal scalability, elasticity, subscription-based delivery models, and more. Hybrid IT, edge computing, zero-trust security, and DevOps are all part of the history of cloud computing.
As containers and microservices are driving innovation today, Kubernetes is at the center of the cloud computing storm. Nevertheless, the cloud covers a broader range of environments than Kubernetes and goes beyond traditional on-premises environments into virtualized and serverless ones.
Finally, we define microservices as coherent and frugal units of execution. Cohesion means that each microservice does one thing and does it well. Thrifty refers to the fact that microservices should be as small as practical, but not less. And by a unit of execution, we mean the fact that microservices are composed of modular executable pieces of code that interact with other microservices (and anything else) through an API.
The other side of microservices
At first glance, it seems that low-code and the cloud do not have much to do with each other, but many low-code providers still keep in touch. After all, microservices are pieces of code, right? So why write them by hand when you can take a simple approach to build your microservices?
Not so fast. Microservices tend to focus on internal functionality that is simply not suited to the visual modeling context provided by low code. Moreover, modern low-code tools tend to focus on building front-end applications (often for mobile applications) and designing and automating business process workflows. Custom microservices are unlikely to make this list of weaknesses.
It is clear from the above definition of microservices that they are code-oriented and therefore may not be suitable for low code development. However, how organizations integrate microservices into applications is a different matter entirely.
Initially, developers were keen on building apps using microservices. The developers, however, had trouble creating serious business functions due to their impatience and their lack of experience with traditional object-oriented approaches. As well as managing, protecting, and scaling them, they had to work in partnership with carriers.
It soon became clear that setting up some kind of free microservice, where any microservice can interact with any other microservice, is a path to overwhelming complexity that makes it difficult to scale the application build effort and manage the final deployment.
The rise of cloud architecture
The challenges of building microservices have willy-nilly helped drive the development of container orchestration platforms like Kubernetes, as well as the broader set of best practices underlying cloud computing, which we call cloud architecture.
The cloud architecture both informs and leverages how Kubernetes organizes containers with pods and clusters, but this is only a small part.
Unlike other architectural approaches, cloud architecture is technology-neutral. Instead, its most important characteristic is how it delineates a coherent and overarching abstraction that defines how cloud computing works.
Abstractions are deliberate simplifications that hide the underlying complexity of technology while providing users with useful insights into the technology. Typically, abstractions are applied in specific technological contexts: compilers abstract object code, virtual machines abstract physical servers, and so on.
In contrast, in cloud architecture, abstraction extends across the entire IT landscape, from on-premises to edge, from cloud to serverless computing.
Basically, we’ve drawn a line through everything we do. In addition to the line, and infrastructure supports the abstraction. Above the line are enterprises, customers, users, and anyone else who wants to create applications that use abstract IT assets.
Once this abstraction is in place, the role of low-code in the cloud world will become clearer. Abstraction aside, we not only have composable microservices – we have secure, manageable, scalable representations of software functionality that enable us to build low-code applications. Whether or not this functionality is a microservice is irrelevant to people above sea level.
In other words, the cloud architecture extends low-code technology’s power to platforms that can support microservices or any other software capability of any size.
Bottom code below the waterline
When done correctly, abstractions hide all kinds of complexity from view, but that complexity still exists. If anything, supporting seamless abstractions actually requires additional complexity below the waterline.
This is the problem with cloud infrastructure. Anyone who has had the pleasure of working with Kubernetes (or any technology in its ecosystem) will agree that the world is extremely complex.
Fortunately, there are core principles of cloud architecture that can help deal with this complexity: lack of trust, lack of state, and lack of code (see my article Why less is more – this is the secret of cloud computing for an introduction to these topics).
Of the three, inattention links cloud computing to low code levels. Lack of code is essentially the “cattle, not pets” principle that declarative descriptions must govern all infrastructure configurations. If you want to change something in a production environment, update its description (or recipe, or manifest, or diagram) and redeploy.
This declarative principle is at the heart of infrastructure as code movement, except that the absence of code in the cloud pushes this movement even further. After all, you don’t want the infrastructure to be code. You want this to be a declarative representation of the desired behavior.
So far so good – just a static representation of the desired behavior is not enough. Think of a single YAML file, manifest, or recipe. How are you going to update, version, test, and manage these views?
Instead, we need an abstract model to represent the desired behavior. Such models do not just capture the behavior itself – they also capture the ability to change such behavior, as well as the constraints on such changes, and enable people who interact with them to implement and manage such changes.