Diego Pacheco Tech blog

Github Co-Pilot is in high hype right now. Co-pilot is an IA/ML tool that allows engineers, coders, in general, to get more productivity from their IDEs and Editors. Right now co-pilot is on early access, I had to subscribe and wait for +3 months to get my access. There are things that need to be improved for sure but overall I can tell it's a pretty cool and yet useful piece of technology. Of course, it raises ethical and IP concerns. Like would private secret source code be used from one company to another? In the land of the AI/ML we never know what will happen so I did not actually use for Real code, to be safe I did not even use it on my main IDEA (IntelliJ for Java)  - I did it in VSCODE where I used it much less and that sense I could isolate from the rest of my personal projects. I have a SlideCast with some thoughts and later there is a live demo with some cool co-pilot in action.

TestContainers is a great project for integration tests, mocking, and even for Chaos Engineering. Scala TestContainers is the library in the form of idiomatic-scala with some sugar to make it even easier to use it. I want to show you guys how we can use Scala Test Containers in an SBT 1.5.0 Project using Scala Spec in order to test as MySQL docker container. So let's get started!

Chaos Engineering is an important discipline of modern cloud-based services. Failure will happen no matter what and it's improved to prove your infrastructure, code, and configurations are reliable and can resist failure and proper recovery. The only way to know is to either by the worst way possible i.e error 3AM on Sunday night or you can test it and sleep better at night :-).  ToxiProxy from Shopify is a pretty useful and interesting solution. It's a proxy that allows us to introduce all sorts of network chaos in our applications such as latency, hang, timeout, and much more. ToxiProxy is written in Go and you can run the server in a self-contained executable like all Go good stuff. ToxiProxy has multiple clients in multiple languages. I will demonstrate some chaos with Redis using the Lettuce driver in Java and ToxiProxy java client library.

Go lang is a cool language to build services. Several DevOps and Infrastructure solutions are built-in go such as Vault, Terraform, Kubernetes, ToxiProxy, Chaos Monkey(CHAP), and many others. Go-Zero is a framework built-in Go that helps us to code microservices in Go. Go-Zero is endorsed by the CNCF foundation. Today I want to share with you a video and POC demonstrating how easy to get started with Go-Zero based microservices written in Go. 

Sometimes applications need to interact with the underlying OS, even with Bash and Process. JVM has a native implementation for Process, in Linux, there are system calls that are invoked. Today I want to show how easy to make Java and bash to talk to each other. This kind of technique can be used for all sorts of DevOps Engineering solutions or automation. So Let's get started!

Factory and Builder and super popular design patterns and still relevant and useful. However what happens if you need to allow others to create objects? That's like a reverse factory where the user needs to define the creational rules. So how can we do that and also have some guardrails and fences to drive some control and even some abstractions, is that possible? yes - that's the factory-kit pattern. Hold one a second why the heck I would need that? Let's say you are creating a game or a modular solution and you need to allow you consider defining customizations within some constraints. 

Reading and writing configs and objects can be more challenging than it looks. As your application evolves and your contract is used across several services, you might need to have Backward Compatibility. Easily we can think about 2 scenarios, the first scenario let's say you have a distributed monolith and you have multiple apps using the same database. The second scenario considers you have an Event Sourcing + CQRS application using Kafka for instance where you emit and read domain events. In both scenarios, there will be breaking changes, so how we can make your parsers and serializers to be more efficient and resilient to change, well: The Tolerant Reader Pattern is here to rescue.

The lazy Loading pattern is very interesting because allows us to make the code starter and also delays expensive computations to an appropriate moment. There is a way to combine this pattern with Java 8 Functional Interfaces and make it even more interesting and java idiomatic. This pattern is used by Spring and Hibernate. You can use it too. So today I have a video and some POC code. Let's get started!

Today career frameworks are a thing, they are pretty popular along with culture handbooks. Career frameworks are an interesting compass no not only to grow up on a company ladder but also to understand what the culture is and how to be effective. Of course, the paper accepts anything and you might write down beautiful things and have a completely different culture in reality. Besides that the fact that your writing down helps to achieve clarity and spread the word. Especially in REMOTE times like we live today where we have little to zero physical contact. Today I want to comment on 3 career frameworks and also see some similarities and opportunities for us to learn.

@Configuration allows you to distribute your Spring Beans across several classes and even jars.  However, with great power comes great responsibility. IMHO you should avoid as much as possible ship configurations with @Configuration inside jars. Because it creates binary coupling on Pojos instances and that has a huge blast radius. In IMHO is completely fine to have Config beans inside in your own service however we are considering a shared libs landscape thats a completely different question and IMHO the wrong move. Let's take a look how @Configuration behavior in sense of ordering and with multiple jars being loaded to the same application.

Modern Cloud Services need to have health checkers. Even some shared libraries might make sense to have health checkers. There is a lot of debate in the community on how the health checker should be implemented. If should just return dummy 200 hardcoded or if should check all dependencies of the services like database connections and other essential downstream dependencies. Which would require us to have a background thread in order to do it in a sane way. IMHO both can work. If you have observability into the other components is not required to make the service look all that, if you dont have or dont have to control to add it, it might be a good idea to have on the service. Besides health checkers, I believe we need to have greater Observability in Services and even for some shared libraries and we should collect metrics and expose config values other key aspects. IF you already have a service let's say running Spring Boot(Tomcat or Netty) or Quarkus, you already have a service. H

Observability is a must-have nowadays in modern cloud services. There are multiple levels and options to provide observability into a service. Logging is the basic one but is well used can perform miracles, metrics, dashboards, and alerts and at the top of the chain however, the true nirvana is to have a self-managed / self-healing system and for troubleshooting a query interface. If you let it sink for a moment and think about it you will realize we often had such power in the past with relational databases with a SQL client for instance. However using a Spring Boot stack using polyglot persistence, with JPA, Reactive Programing, Multiple property sources, and Beans it's easy to get into the application and shared libs internals. So what's best? To have access to all properties at runtime and spring beans and be able to execute CODE in a very fluent way. That's where Groovy comes into the play. Inspired by Gabor Bata work , today I will show how we can get that and more w

Configuration management is an important aspect of any service. However, configuration management is way bigger than just using a source control system like Git. CM(Configuration Management) is about Branching Strategies, or avoiding branches might be the best strategy in the line of Trunk Based Development. Besides branches and configuration management versioning systems like git we also need to be able to version applications in a proper way. It's pretty default to use semantical versioning. i.e: $major.$minor.$sec-patch however sometimes is important to know what version the app from inside the de application.  Java has a way for us to version packages(which can be used as modules) and we can know what versions we are getting, thats interesting for building modular monoliths and also for troubleshooting reasons, imagine you deploy to service and want to be sure you are running a specific version no matter the name of the jar is. Java JAR can have a build number or whatever versi

Some years ago, every backend engineer wanted to be doing microservices . There was absolute hype. A vast majority of the market joined the microservice bandwagon without previous expertise in SOA. Some companies were successful. Still, several companies ended up in the worst place they were before. Therefore we see the Death of Microservices . IMHO there are many reasons why that happens to name a few: Lack of proper architecture skills in SOA , Lack of Isolation, Lack of Analysis, and jump to solutions too fast. Once you start distributing code across several code bases with multiple contracts, it is better to be correct because the rollback is a multi-year migration project and not easy to sell. How does that kind of thing happen exactly? In Microservices, the way to go is to use the Strangler Pattern, however by applying the pattern in the wrong way, thats where we arrive at the worst outcome: A distributed monolith. 

The DORA DevOps Report 2021 is out. Thats a very interesting report about DevOps and SRE covering 32K professionals over the world during the COVID-19 Pandemic time. We are in difficult times and having this data is very very interesting. IMHO We lose the battle, like Agile but at the same time, the report shows some interesting findings which always gave me hope.  I have read this report since the beginning and always find it interesting and super useful. Today I want to do something slightly different, I made a video commenting on some of my thoughts on the report. I hope you guys like it, so let's get started!

  Shape up is the new Basecamp book(former 37 signals). It's about product discovery. A book is a form or flavor of Dual Track agile . Is pretty interesting because it also blends with some Lean Startup ideas. 37signals/Basecamp was always an interesting company since they did not fit on the classical enterprise-like company neither typical silicon valley company. The books are often culture-heavy and show how they do business. This book is about product development, Discovery, Dual-Track agile, and a different way to manage scope. Basecamp explores the flexibility of Scope which to give them credit not often is explored. The book also shows obvious XP reference by tracking progress with Big visible charts and using lots of visuals to avoid heavy unrealistic planning. ShapeUp is cool but we also need to keep in mind they have executive buy-in since they literally run the company and do not rely on VC/Seed money, so this gives them the ultimate flexibility. Today I made a slide ca

In the matrix movie(classical and awesome movie), there is a classic scene where Morpheus challenge Neo's understanding of reality and offers 2 pills the Blue one which would keep the status quo, and the red one, which could be painful but would be the reality.  If you have a successful company with software thats the reality of the industry. In other terns, the discussion can seem as should we re-write the software or should we strangle it. Re-write software and even strangler patterns have cases of success and failure. Before we enter into the trade-offs of this complicated dilemma lets us understand the forces which create problems and opportunities that are around this discussion. Let's talk more about the context and their trade-offs. 

Big Companies have lots of software. The Software industry moves pretty fast. However, not all pieces of software are moving that fast. There are always competing priorities between news business domains, acquisitions, new features, improving user experience, fixing bugs, improving security, and being up to date. If you have good architecture, isolation of databases, proper contracts, and tests, migrations can be much easier. However, not all pieces of software have the same conditions as you might have orphan software with no owners, old tech, lack of testing, lack of isolation; in those conditions, migrations could be pretty challenging. There will always have migrations one way or another. In the last decade, lots of companies have been migrating from on-premises to the Cloud. 

Tickets! Some people love them others hate them. I for sure dont have much love, however, I can see both sides of the same coin. There are lots of tracking systems such as Bugzilla, Track, Jira, GitHub Issues, and many others. There are companies with complex workflows with lots of approvals and complicated steps.IMHO there is little value in complex workflows, I understand the reasons why companies might arrive there but still think is not the way. Tickets can be used for multiple reasons, some could be valid, and others could be actually bad practices, meaning hiding inefficiencies. Let's take a look at the 2 sides of the same coin.

Some technical problems can get quite challenging. It's pretty common to feel like you dont know how to approach them or even panic. Especially if you are starting on technology. Even the most accomplished and experienced feel the impostor syndrome . IMHO if you do not panic is already 90% done 😉, then the next important thing is to keep going. Small incremental progress is essential emotionally wise in the sense of confidence-building. Small wins can be addictive. The first steps are often the most difficult because we are talking about a technical discovery process.  The tech discovery process might sound like something new and fancy, but actually, we are talking about something as old as the rocks: Analysis. But! How do we do this analysis? Which leads us to the questions such as: How to approach complex tasks? How to break problems down?