Diego Pacheco Tech blog

AWS Lambda is an awesome Serverless implementation. Lambdas are a bit tricky because they are ephemeral and short-lived so either they call another lambda or they will mutate some external state. Either an external data store like RDS, Aurora, S3, Kineses, Elasticache or they will call another microservices that does state mutation. In order to properly test Lambdas, we need to design for testability, the easier thing to do is always create more lambdas because you can check the input and output. So lambdas are not pure functions(functional programming) they often need to have side effects. So AWS has this library that makes it easier to test lambdas for Unit Testing / Mocking but also for localized Phased Integration Tests. You can mock source events like S3 ones, and also mock the context, and just test your lambdas with Junit. So I made a simple POC and video I want to share with you guys. So Let's get started!

Everybody knows there is no Silver Bullet. We all know there is no one size fits all, however, we still look for it. It happened over and over and for sure will keep happening. Before when there was SOA , people were doing SOA wrong and want to fix all problems with ESB. So there was the SOA Rest Guerilla movement ; Let's stop adding things on ESBs and move all to services. Now everybody has coded into microservices, they have distributed monolith in most cases and people are considering removing things from microservices and moving to Kubernetes . Why just run stateless code there right? If we can run all the things there like stateful databases, IoT/Edge, BFF, ML. However, there are other computing models. Most of the couples have Virtualization(EC2 on AWS), Containers (ECS/EKS on aws), Edge(Lambda on Edge for AWS), Serverless (AWs Lambda).

This is the 3rd part and last one on the series: Reflections on Serverless from SOA to Serverless. On the previous parts 1 and 2 I was explaining how software architecture evolved in several movements and how much we need to change our mindset in the sense of Culture, Movements, and Experiments. Our tools are changing pretty quickly and multi/poly cloud will be soon a reality for most companies. Even if so few companies have this problem in sense of availability and active-active global biz, most of the companies can benefit from multi-poly cloud in sense of getting lock in free from cloud vendors, cost reduction for better and multi offerings, better solutions for specific problems and much much more.

In the previous blog post , I describe the architecture evolution from SOA to Serverless. For this blog post, I will continue to talk about the same subject in the sense of strategy evolution and architecture strategy. Business value does not come only by adopting new technology but also from a new way of thinking or the right mindset shift and the right understanding about tech culture and vision. Most companies have the right Tech view and often don't see themselves as tech companies because they think this business is logistics, sales, health care, insurance, finance anything but tech. Nowadays several companies depend so much on Technology in order to service, prosper and deliver better customer experience(CX) . However, tech is often seen is a COST CENTER rather than a VALUE center. Because often IT fail to DELIVER and SHOW value to the business. That's why some many companies are looking into the DevOps movement and other movements like Digital Transform...

New technology is great. It's very important to open space for new ideas, better solutions, cheaper, faster and exciting new things. However, even with technology, there are principles and lessons learned with previous technologies we need to carry on otherwise we will keep making the same mistakes and we might not take full advantage of new tech. Why? Because often new tech requires a new way of things and often times also require to keep some things from the previous movements. Companies want to do Serverless now a day, often because cloud vendors are pushing that hard and because of the short term cost benefit. However, in the long run, Serverless solutions might be way more expensive than in-house solutions using OSS. There is no silver bullet, you need to understand what you are doing in order to take full benefit from new approaches, techs, and ideas rather than just moving everything from on-trend to another.  I want to share some thoughts from several architecture...

Today I want to share some experiences I had in the last 2 years with AWS Lambda as a Serverless solution for Microservices Remediation. This was not a single effort from me only but a team effort. The lessons learned I want to share with you today was not only in sense of Serverless but also in sense of DevOps Engineering. DevOps Engineering is the norm today. I really can't see a world without it. Code it is the lingua franca of everything around IT. Currently, there are more and more abstractions and solutions rising for DevOps Engineering, chances are we will need code fewer things as the time pass. However, as we push the boundaries of innovation we face new problems and new problems will always require better solutions. DevOps Engineering is great however it's not a FREE LUNCH at all, like microservices, which are great too, there are lots of COST that are introduced. There is a requirement do structure and lay down teams in a different way and also there is a need ...