The End Game for The Cloud? Towards A Serverless Infrastructure
The "shall I move to the Cloud?" question has passed. Organisations are moving fast into the Cloud, and the first move was basically to move our current servers and services into a public cloud environment. But why do we even need servers? Why do we still need firewalls for TCP ports? Shouldn't we just say that when Bob sends a message to Alice about exams and that Trent will get a blind copy of the messages?
So why can't we just write an event-driven system for our corporate infrastructure? Our world, is event-driven, and generally, we reduce the complexity of our systems by just defining events. "When there's an access to the FTP service of upload ... do this ...", "When there's an access on a column on a database ... do this ". In an IoT world, with billions of disparate devices, it is the only way to go. And if we are to create truly citizen-focused systems, we need to define the events which trigger. How many organisations could crisply define the operation of their infrastructure and all the interactions that happen?
Rather than just defining a server running Exchange, we could have some code which triggers on "When Bob logs-in open up his mail box", or "When Alice changes the marks for her students, send an update to the exams office". This is a world where the complexity of servers moves us towards "The Cloud" as a computation resource. In this way we write rules based on events and enact them in the Cloud. There's no concept of running Exchange or Web servers.
Over the past few months, we have been investigating AWS Lambda, and its potential is amazing, and really changes the landscape for developers. Within this we have the concept of serverless architectures and where we can rapidly support new products and services. The companies which adapt to this changing environment, are likely to move faster into the market.
Serverless architectures are often defined as Functions-as-a-Service (FaaS), and where we create Compute containers which are triggered on events. We then have no need for servers, and where the Compute engine manages the code which is required. While AWS Lambda provides the most extensive support, others such as exist, such as Microsoft Azure Functions and Google Cloud Functions. Azure allows the support for a range of programming languages.
For Open Source Serverless frameworks we see OpenLambda, LeverOS and Funktion. Each of these aim to reduce the complexity of the infrastructure by creating microservices. As with many current developments, it is written in Go and is based on Linux containers. When it comes to serverless API frameworks, there are many to choose from including Kappa, and which integrates with AWS Lambda.
Within AWS we gather notifications from S3 data buckets, HTTP requests, database tables, CloudWatch, so on. Overall it is aimed at reducing complexity and is especially useful for supporting an IoT backend infrastructure (AWS Greengrass) and with Alexa support.
Azure has made a slower start than AWS and is currently a long way behind. There are moves towards it, but it is still not a pure implementation of serverless technology. The monitoring of events does not quite as integrated as it could be. Overall too it defines functions with input and output bindings, rather than with dedicated services.
For serverless architectures, we imagine a health care system, where Bob the GP sets up his own rule for his patient (Alice):
"When Alice's blood pressure from her Fitbit goes over 140/90, send me an alert on my mobile phone, and copy the family in."
This would be a world without the complexity of IT systems getting in the way, and is the only way forward, in order to build trustworthy systems, which put the citizen at the centre.
Conclusions
The architectures we have are old ... they are legacy ... and we can't secure them with old methods. The concepts of firewalls and servers dealing with a complex set of interactions does not work anymore, and the complex is far beyond anything that we can currently cope with. It is similar to when I first got into computing, where we wrote programs which had to respond to every conceivable way to interaction. Then along came event-driven programming, and we considerably reduced the complexity of our programs, and can just run the code and wait for events. In 10 years time, you may well see the concept of running servers as a rather archaic method of implementing IT.
Those companies who adopt serverless architectures now will be able to move the fastest, so get ready ...
"The Network is the Computer!"
Administrative Assistant
7 年Incredible !
I support your IT projects in Japan. (Disclaimer: I use AI but not on LinkedIn. Everything I post is in my own wording without using any AI or bot)
7 年Nice technology for orchestration. Nevertheless, it will also devlop its own complexity when you start combining x1000 services for realizing the details and subtleties of a real business. SLA contracts and interface management also required. As for IT Security: Need to get much more serious about implementing Application Security than ever before. Now the paradigm should be that each service must protect itself. As you describe, not possible to count on someone else or leave this responsibility to a security infrastructure any longer.
Senior Information Cyber Security Analyst @ Equiniti | Certified Information Security Manager, CISA, CISSP
7 年Simple answer yes and I too appreciate Lambda but the communities of trade must be incorporated your blood pressure example is great, however I could see a world where an insurance policy might have an equivalent event stating if 10 such events are logged then insurance cover is revoked. The technology is the easy bit ...
Availability is the most important part of security, I have a Security portfolio built with this in mind.
7 年How do you feel Lambda type servies which exist no more than 5 minutes will meld with ioT bill?, there was an excellent session on Ansible tonight I can share if you are interester (MeetUp at Sainsbury HQ)