Talent Garden Milan – 09/22/2016 15:00   Starts the AWS Lambda Zombie Workshop.
I come just in time in the TAG home, my first time in a startup hub. A fresh environment but spartan, essential. What you need for a startup, nothing more.

I confess to being a little afraid because I do not feel a Cloud guru. I’m studying to pass AWS Certified Developer exam, I know well enough hacking the console, set up EC2 instances, S3, RDS and other little things but I certainly do not feel like an expert and I hope to be worthy of a workshop on AWS Lambda. Especially… to figure it out. 😉

But I know well what can do a Lambda AWS. In short, can run code more or less complex without having to worry/think about the infrastructure behind it. That way, you grasp the potential but may seem nothing special, or, at best, seem that the problem solved is merely to not have to think about managing a server. So far from the truth …

Main event speaker Danilo Poccia, I discover soon be one “tough” in AWS, specifically Technical Evangelist, previously Solutions Architect and author of a recent book entitled “AWS Lambda in Action – Event-Driven Applications Serverless“, a title that summarizes quite well what does a Lambda.

I’m sorry but I have to say … The only drawback in the organization of the event an insufficient number of power strips to allow everyone to connect their computers. I am among those nerds … too far from the few outlets that are, of course, all full … which will pay towards the end of the event, forcing me to an early retirement because the battery died …

Earlier Danilo makes a keynote speech, and an overview of the various services in the Amazon Web Services console. In Italy, you know, the cloud chew too few and the audience might not know about the services, even if, given the typical geek approach of a workshop, you can expect to have to do with people who at least know what you are about to speak.

It ‘s time for a break for a little refreshment, generously granted by the organization, and finally we move on to “serious.”

At the base of the need for a product/service as Lambda is a new trend in the architectural conception of the software, web-service API and, more recently, of micro-services. Even if confirmed by concrete needs, is still the question always lawful:

why use micro-services? Simple answer …

old 3tier architectures, though solid and responsive to the need for increased productivity, obtained with the reusability and separation of powers, tend to explode quite easily in terms of complexity and are still highly dependent on the technologies used. Micro-services architecture , however, should not follow the technology, but follow a business logic (Business domain); should be loosely coupled and is convenient to adopt it in the presence of independent contexts (bounded context), the latter corresponding to the areas of business/corporate services.

Advantages? … many of these

• Micro-services adopt the principle of individual responsibility and are indipendent deployment
• It can be chosen the most appropriate tool and then different application stacks
• Adopt new technologies, and more …

Of course, if you are not careful, a single micro-service may soon become too complex. It ‘so important to succeed, whether you are migrating from a 3tier application or if you are conceiving the architecture of a new software, to break down a complex workflow for small independent and simple segments, a sort of unit of work, in fact they are the basis of a development TDD/BDD.

Yeah, but how small? A rule of thumb is that a micro-service should be able to be written/rewritten completely in two weeks by a small dedicated team of about 5/10 people, who have to follow the entire life cycle.

If the software is large and complex can be divided with the development team dedicated to different features (Feature Teams).

Description of the features, that can use the Sync mode rather than Async, should be absolutely defined. When you can move a process to async, you are decoupled the process, and this is all well and good, but the impacts are expected to result in the application of asynchronous programming.

Adopting an architecture in micro-services and small teams, in case of bugs or delays, there are no moments of stasis for other developers to the resolution of the bug, even if you have to use a series of measures. Some of these must follow the Postel’s law, better known as

Robustness Principle: be conservative in what you do, but free in what you accept from others

In essence, it should ensure that the code that sends commands/parameters strictly complies with the specifications, but at the same time the code that receives these commands/input parameters must be able to accept a larger number than expected, without generating errors.

Also, use a minimum set of privileges to the execution of a process and adopt an authentication system with single sign-on, as it is not thinkable having to authenticate to each service, as well as it is absolutely essential to include a logging system for each individual significant step inside the Microservice, otherwise the debugging process would really be “a pain in the ass” …

Last but not least … Think always bearing in mind the failures and how to use the system with degraded functionality.

Danilo said many more things and definitely better than me, also doing some practical example of how you create a Lambda, how do you upload the code on AWS as a lambda through triggers or http endpoint (Lambda is activated and executes code only on activation of the trigger and is expensed for millisecs actually used; that is, in practice if there is idle there is no fee …), the use of AWS API Gateway, which acts as a proxy and protects against ddos attacks , all well equipped for some use cases, like that of the Seattle Times in which the photographs are stored on S3, Amazon’s storage service, and then is launched lambda making the resizing of the image in the established formats. And still others use case, passed too quickly to be able to take coherent notes …

Now in theory should have come the better, the practical part for us. The formula chosen, a sort of hackathon, instead, seemed rather unhappy to me. Not because it was poorly organized, but simply because they did not allow, even given the limited time, an improvement of attendees’ knowledge and therefore an enrichment in professional terms. I would have much preferred a practical exercise for everyone to create a Lambda and all the necessary configurations, so as to bring all those present to an acceptable level and then subsequently pass to hackathon.

Not to mention the fact that at this time my computer did “poof” … black … dead battery and I could do nothing but say “goodbye and thank you.”

Some useful links:

• https://github.com/awslabs/aws-lambda-zombie-workshop
• https://aws.amazon.com/it/training/intro-to-aws-labs-sm/
• https://aws.amazon.com/it/events/zombie-microservices-roadshow/
• https://aws.amazon.com/it/blogs/compute/surviving-the-zombie-apocalypse-with-serverless-microservices/
• http://www.slideshare.net/AmazonWebServices/workshop-aws-lamda-signal-corps-vs-zombies
• https://medium.com/aws-activate-startup-blog/surviving-the-zombie-apocalypse-by-building-serverless-microservices-bd115913d80f#.mfmew8kpq
• http://redfoxbook.com/18/1535309318

From the site XPEPPERS, organizer of the event, I steal two pictures that immortalize me … I could not give up this little moment of ego … 😉

close-up of my shoulders, on first visible row

me, the first from left on fourth row