Alberto Corrales Garcia

Introduction In the era of Microservices, you are probably designing or consuming one or more Web Services. As a result, you might be aware of the importance of having a good definition of your web services, since that is what clients and developers will use to know how a web service can be used. For that reason, you should have a clear and easy way to define and understand your Web API. In order to help you to make a good definition we have REST (Representational state transfer) , which is a software architectural style that defines a set of rules to create Web Services. I'm not going to go into details about RESTful, because there is enough material for a full post and it is out of the scope of this post. But I might write another post about REST, since even nowadays I see some crazy stuff when it comes to Web APIs design. Well, imagine we already have a really awesome definition for the resources of our Web API, and your clients are going to be really excited to use it,

  Introduction Recently, I have had the chance to use Azure Functions as candidate for the design and development of a service, which will be delivered as Software as a Service (SaaS). Azure Functions is a relatively recent technology, and as a consequence, I have realized many people didn't heard of it yet. For this reason, I would like to write this post as a brief introduction and my personal experience using it at the present. What is Azure Functions? Azure Functions provide a framework to build and manage easily serverless oriented architectures. The idea behind Azure Functions  is that you have a piece of code, which provides a functionality. In order to execute your piece of code, Azure functions introduce the concept of " trigger ". A trigger can be an HTTP request, a timer, a message in a queue, a modification on a Blog, etc. In addition, Azure Functions provides the concept of " bindings " Binding to a function is a way of declaratively connect