So, how is cloud architecture evolving? In this latest installment of the Armchair Architects series of the Azure Enablement Show, we discuss the evolution of cloud architecture for four topics:
- Containers and collaboration environments
- Machine learning
- Serverless computing
- Low-code/No-code development.
We’ll cover four topics in two separate posts to minimize reader fatigue. The second two are topics are covered in this one, while Containers and collaboration environments and Machine learning are in Part 1.
While these posts are detailed, if you’d like to get straight to the videos (averaging about 10 minutes each), feel free at the following link.
Serverless:
Three dimensions of serverless:
- Environment that has an even with an observable state is shared. You have a piece of code called a function (or Lambda in AWS parlance) that is considered serverless because this event exists without a server being called and is simply in the environment. You can then have another piece of code that observes it and take some action on it. This is known as the functional programming model. This concept started the serverless revolution.
- The next thing is an operational pattern. It generalizes the notion of Serverless, as it states that it does not care about the underlying infrastructure – just that there is an event and a reaction to that event. For instance, if you run a query instance against a SQL data warehouse, you don’t know how many instances of that SQL data warehouse are running – and really it doesn’t matter.
- The last piece of serverless is the evolution of the cloud consumption business model. We moved from charging for hosting infrastructure and code to invoking the function.
A a collection of functions (code and events) can now be considered an application. If you change one or more of these functions, then you effectively have a new application. The events or triggers will determine how the collection of functions behave. These collective behaviors will drive outcomes or output defined by the application design. You need to think about what happens when an event occurs: what is the next step, and then what are following steps? It’s essentially a different way of doing workflows.
The notion of workflows are supported by durable events, where once Event A happens you may need to wait until Event B occurs before you can take action on Event A. That is why Azure has durable functions and non-durable functions – or stateful and stateless programming.
Logic apps, for example, sits on top of durable functions to make it easier to write rich workflow applications. Now non-technical teams can implement and automate business logic without as much developer support.
One misconception of serverless is that functions are the primary or principal actor. There are several others, such as serverless Kubernetes, Logic Apps, serverless app services and API gateways. Application architecture has evolved to consider consumption of these elements and not just the implementation of code in a function boundary but also integration code and its state.
So, back to the question that haunts us all about micro-services: what is a “new release”? Unfortunately —or maybe fortunately—the answer starts with “it depends”. If you can write functions that are truly stateless, where the code take inputs, runs a computation, and generates an output without storing data in durable forms, then that code could be considered an app with ‘new releases’ anytime that function changes. However, if you have a collection of durable functions, then you need to manage this collection as an app. As a result, the historical management and versioning challenges (i.e.: versioning mismatch) continue to be important considerations.
Low-Code Development:
Low-code (or no-code) development for applications is not a new concept. It strives to democratize development in a similar way as decades ago Visual Basic expanded the number of developers from thousands of C++ developers to hundreds of thousands of developers creating Windows-based solutions. Low-code takes this concept to non-technical professionals. Although this notion is great for productivity and usability, the maintenance and performance of these apps can be daunting to say the least. Now non-technical application authors need to learn about application management, documentation and, application deployment. Without a clear understanding of these considerations, the environment can quickly become chaotic. The good news is that platforms and tools have come a long way since Visual Basic. For example, Microsoft’s Power Apps platform provides many of the platform services needed to maintain a healthy application lifecycle and governance paradigm.
So, what should a domain expert know about writing code? What type of guidance could software architects give these people? Eric says that it’s primarily being able to ask/answer well-placed, basic questions, like deployment, number of users, and dependencies. Another important aspect that architects have helped domain experts, though indirectly, is through their careful consideration of how casual users leverage features/functionality of the platform’s services. Architects have helped to look at and resolve many software pitfalls that most domain experts wouldn’t see or understand.
Then there’s the fusion developer who wants to expose their professional code in a low-code environment. This sort of scenario (which is highly popular) is just beginning its journey. We’re seeing a lot of progress in API management but there’s still a long way to go, given the signs of misbehavior or over-usage and so forth.
One other consideration is whether a low-code application is the right method to truly fulfill required use cases and user experience requirements. In some instances, a traditionally developed application and associated architecture will be required. We’ve seen a lot of cases where low-code solutions are being utilized in unnatural ways to compensate for what a well-designed and architected code-based application would be able to accommodate.
Conclusion:
One thing is certain: architecture has been changing since the beginning of software development and that will not change in any scenario. Developers, software architects and IT professionals will need to stay on top of these trends and their implications. The Armchair Architects, Uli and Eric, with David Blank-Edelman will be there to help! Let us know in the Comments section below what you’d like us to cover next!
For more details about these two videos, please watch them below. And please any feedback or comments! We read and respond to all of them!
