Diego Pacheco Tech blog

Some time ago I was sharing my experiences with a Dynomite Remediation Process I wrote. Iḿ using remediation systems for a while and IMHO the add lots of value since they automate manual Cloud Operation work and save time for people. Currently, I refactored my Remediation code and now the same code can support Dynomite / Dynomite Manager but also Apache Cassandra. There are very similar concepts between Dynomite and Cassandra Remediation such as discovering AWS EC2 Ips to be remediated, AWs Resourcing(Creating SGs, Deleting LCs, Updating ASGs), Health checking(Is the node up and running? Could I remediate right now or you are in the middle of a backup or just booting up?). Once I identified that core concept I was able to create a high level and generic design for Cassandra and Dynomite. This is great for cases of Patch / Fix(apply a new AMI) or Scale Up(Increase the memory or CPU for instance). Although that the main use cases and most important ones there were some c...

Cloud Computing is the default today. I do believe the future is containers and multi-cloud solutions. However today I work a lot with AWS . There are specific endpoints such as S3, AutoScaling , Route53 and other that are among the ones I use more in my day to day work. AWS API is easy to use however not no easy to test. Distributed systems tend to be hard to test. Having quick feedback is very important for engineers. There is some kind of tasks that need to interact with AWS APIs like S3 for backups for instance. However, if you need to wait to deploy in AWS to test it because is basically impossible to test it locally then we have a problem. We need to be able to do end-2-end testing however while you are coding or doing some troubleshooting is important to do things faster. There are 2 specific projects that can help us with this task. TestContainers and LocalStack . Today I will show to use LocalStack and TestContainers together with JUnit in order to do unit tests m...

DevOps Engineering is often "perceived" as a operations matter. In fact, it's true but is not 100% JUST ops. There are some blurred lines between engineering and operations. When we take a look at the DevOps ecosystem we can highlight some great tools like Ansible, Terraform, Jenkins, Packer and so many others. Provisioning, Release, Observability, and SRE are different aspects of a broader DevOps adoption. The higher benefit comes when we start applying more engineering to DevOps. It's very important to have good tooling around. When we think about tooling engineering makes a lot of sense, however, even outside of the tooling space there are areas where we definitely need an engineering injection like Cloud Production Operation Automation. Releasing is the easy part, things get complicated when you automate the operational aspects of your systems. It sounds so meta or Inception(If you watch the movie ) but Systems managing Systems looks the way to go for me. This ...

Working with the cloud is great but it's not easy. The Cloud allows us spins machines pretty easily, however, update these machines are not that an easy task, especially if we talking about databases. Today I want to share some experience with remediation process I've built for Dynomite in my current project.  I'm using NetflixOSS Dynomite in production(AWS) for more than 2 years now both as cache but also as Source of Truth. I need to say that is rock solid and just works. However often we need to increase some machine capacity, i.e: Add more memory or increase the disk size. There are times where we need to apply patches on the OS - I use Amazon Linux on Production on EC2 and recently there was the Meltdown and Spectre situation. Other times there are telemetry or even provisioning and configuration bugs that need to be fixed.  No matter the reason you will always need, time to time, change something on the underlying AMI or in the Java or C application which is ru...

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 ...

Kanban is a Lean tool. It's focused on the psychological part of the work. In a nutshell, you manage the system via constraints and you don't manage people. I used kanban a lot in the last 8 years. When I started I was a Software Architect | Coach in not-so-traditional SOA projects.  Today I work a lot with DevOps Engineering and Cloud Computing and I don't work with 2 weeks sprints but with quarters which are 3-months length buffers of work. You might think as a quarter as a super big sprint. There are several different kinds of classes of work like (A) Support for Developers, (B) Tuning, (C) Stress Testing, (D) NoSQL Development, (E) Telemetry and Observability, (F) Distributed Tracking and so on and on. I'm working on CORE team with other architect and DevOps Engineers. For a long time, I was using kanban metrics and sheets pretty religiously. Because I was working with Big Teams(up to 33 people) and multiple teams who had to deliver on time. As more close y...

C language is old(since 1972 to be precise) but still kicks ass. Some folks consider C too low level. IMHO is not that low level, actually, there are some abstractions and syntactical sugars I miss in C but IMHO is something you can leave without since you are befiniting from better performance. Many developers care too much about syntax today and not many care about performance. It really depends on what you are doing and what kind of company you are. There are languages that are more productive than C for sure, however, once you get how to do things properly is not bad at all actually is quite good.  Most of the big languages like Java, C#, python, ruby are actually based on C. C often is a language the most of people fear it. Maybe because we got used to much with languages that do a lot of things for us. IMHO is not that hard, it's just a matter of taste, after some time I learn to enjoy working with C professionally and today I like it a lot. But this really depends...