Microservices: Azure Functions - say no to the server

I began to notice that recently programming has its own fashion, its own trendsetters, fashion trends, and so on. Now it is fashionable to talk about microservices and containers, as the possibility of a simple implementation of microservices. Although, at once I will make a reservation, microservices <> containers. Containers have much more application scenarios than the implementation of microservice architectures. So, I suggest to talk under the cut on the topic: “Why are microservices and why now?”



Technology development trends are such that now powerful computing and storage resources are becoming more accessible both locally and in the cloud. If earlier it was necessary to find at least some computational power, now it is increasingly becoming a task not only to find it, but also to apply it with maximum benefit.

The obvious use of microservices is to increase the efficiency of using the available computing power when scaling a solution. It is important to understand that the benefit from the use of the microservice architecture comes in this case only when the additional infrastructure necessary to manage the microservice solution, as compared to the conventional monolithic (multi-link), requires less computational power than we saved when switching to it. Thus, in the general case, the benefits of using a microservice architecture are not as obvious as they were at the beginning of the paragraph.
')

Then why all this?

And here is the next level of history. What does microservice architecture allow us because of its disconnectedness? It allows you to add new features to the system in significantly less time than is required for a monolithic system.

Thus, the use of microservice architecture can bring quite understandable value to the business - reducing the time to market for new functionality in the product.

Let's sort the classic example

Imagine a system of online payments. And plunge into the past, when the functionality of online payment systems was measured by the possibility of making various payments: for a cell phone, satellite television, and so on.

So we need to add a new payment partner.

In the case of a monolithic architecture, we are tied to one language, a framework, a platform, and are forced to develop each new functionality using a choice made by someone a long time ago. Even if the choice of another platform and framework will reduce the development time several times.

Plus, before the release of the system into combat mode, in an amicable way, we must conduct a full cycle of release testing of the entire system.

If our system is based on a microservice architecture, in general, we are not tied to a language, framework, or platform, and we only need to test a bunch of modules with which our new payment module will interact.

You have reduced the launch time of new functionality, and competitors with a monolithic system continue to develop and test, besides losing customers who desperately need this particular payment partner. And we are perfectly able to withstand this influx of customers and requests, because, due to the chosen architecture, we can scale this payment module more efficiently, because we can scale with it only the modules it needs, and not the entire system.

Our product has gained an advantage, sales are growing, and now our marketing has something to tell you again.

The director provides additional funding to the technology unit.

Serverless organization of code execution

It would be possible to finish on this positive note, but pay attention to an important part of the microservice architecture - microservices are as much as possible separated , and some are needed only for a very short time to accomplish one task. And here comes another story now that is fashionable — serverless — serverless code execution.

If to simplify a little, the idea is that we do not reserve servers or computing facilities in advance and do not keep them ready. We receive resources for the execution of the code on request and pay only for the execution time and some resources that are used during the execution.

The result is a savings in computing resources, and the technology itself is a convenient pattern for implementing event driven architecture. In the Azure cloud, this pattern is implemented through Azure Functions. Functions can be written in various languages, including JavaScript, C #, F #, as well as using Python, PHP, Bash and PowerShell. All this can be done in a simple web interface or you can download pre-compiled code created, for example, using Visual Studio .

A short introduction to the functions can be viewed below.

Typical use cases and overview of the Azure App Service technology platform

I also invite you on March 16 at 11:00 am (MSK) to a webinar , during which I will talk about typical scenarios for using the Azure App Service technology platform.

Using PaaS services to which the Azure App Service suite belongs can open up new opportunities for solving business and technology challenges. The hardest part is choosing the right service from that large list of available PaaS services. To do this, you need to understand what each of the services provides and what typical tasks it solves.

Participation is free .

And for dessert

Now there is the Azure Functions Challenge , where you can complete tasks, develop Azure Functions, test your developer skills and get badges for it. :)

We remind you that you can try Microsoft Azure for free here .