Diego Pacheco Tech blog

We are in the holiday season. You walk into any Starbucks and see the Christmas decorations. Lights and Christmas trees are everywhere, and the advent of code is still rolling. Whether Xmas is summer or winter, You can get some specials and flavors only on Xmas. Now, you must wonder if this is a technical blog post; yes, 100% it is. I promise there will be a point at the end. Let's imagine a very different coffee shop experience; in reality, it's not how I will describe it, but hopefully, it will help you to see my point. I'm pretty sure you've gone to a coffee shop before; how it works is simple: you look many for what coffee + snacks you want, you get in line, pay at the cashier, and then the barista will brew you coffee, warm your food, and you will be good to go. If it is a good place, they will call you by name. Now, let's imagine a very different experience. Consider this the upside-down Xmas experience. However, if you want to name it, I will give you my nam...

After 7+ months of hard work, my third book is out. Introducing:  Continuous Modernization : The never-ending discipline of improving microservices, monoliths, distributed monoliths, individuals, and teams at scale. Modernization is something I have done over and over in my life. Modernization is something that all companies need and will always need. The need for modernization will never go away, even with LLMs and AI. Technical debt, Anti-patterns, and bad decisions do not take days off. Complexity never shirks and continually grows. Companies do not stop getting bigger and doing more and more software critical to growth, delivering value to customers, and staying competitive and relevant in the market. We need a better way of doing software to drive the best outcomes out of us. Continuous modernization is the counterforce to technical debt and anti-patterns. Continuous modernization is how to continually improve, even when you think it's impossible and nothing can be done. We ca...

After 1+ year of hard work, my second book is finally out. Introducing: Principles of Software Architecture Modernization: Delivering Engineering Excellence with the art of fixing microservices, monoliths, and distributed monoliths. I've 20+ years of experience with technology and have been an architect and a technology consultant for most of this time, software architecture is a deep passion of mine. It is a huge pride and joy, for me to come here today to share this with you, my friends, and dear readers. 🎉🎉🎉 I deeply appreciate all the blessings God has given me, from my family, my daughter Clara, my wife Andressa, my work, and my friends. It was not easy to write this book 📘, there was sweat, blood, and tears, lots of remote work with my co-author Sam . Rest assured you are getting my passion, vision, and perspective of software architecture. First and foremost the book is about principles, tradeoffs, and software architecture design at the heart of complexity. The book is ...

Testing is essential . Testing requires diversity, from integration to chaos , from your local machine to production . Writing tests not always is fun because sometimes is hard to write tests because not all contracts are good, and clean and went through a lot of thought processes. Is easy to blame the design, architecture, and even the implementation, but are we sure we are not missing anything? Something that is hard to test very likely will not be tested. Testability is a good property of any design or architecture sure. Making good solutions that are easy to test is a good thing. However, mocking is often taken for granted, meaning is seen as something that is just good and has no drawbacks, but that is not true. Everything has drawbacks. Integration tests are often seen as bad practices and people tend to lean toward unit tests instead. Just keep in mind Integration tests don't require mocks. Unit tests often require mocks to keep them isolated and cut off external dependencie...

Distributed Monoliths are the worst. Nothing good comes from distributed monoliths. No one wants to have distributed monoliths, and still, they are very common in the industry. Complexity just gets bigger, our industry just gets more and more entangled. Complexity has everything to do with distributed monoliths. Distributed Monoliths are very complex, much more than monoliths. How can you avoid a trap? By definition, the only way is not to follow into the trap. Understanding the trap is how you can avoid it. However, some traps cannot be avoided because there are bigger forces like acquisitions, pandemics, economic downturns, wars, or time. Time can easily be the biggest trap of all. We need to learn how to work effectively with monoliths and distributed monoliths because they are to stay and we can't ignore them. Fishing monoliths is a long-turn battle, that requires persistence, patience, and allies. Let's start by understanding monoliths and Distributed Monoliths a bit more.

  Building service is easy. Isolating that service, it's easier said than done. Anyone can build any service with any technology or stack. However, would this service last, or will it become technical debt? Many organizations trying to go all in with microservices end up with distributed monoliths instead of isolated services. The result is more complexity, less business value, and slower lead times. We had many movements and many different technologies and styles of architecture in our industry. From SOA, Soap, ESBs, BEPL, REST, Event-Driven, gRPC, GraphQL, Microservices, and Serverless, we still cannot get services right - did you wonder why? IMHO it's all about principles and isolation is at the CORE of everything. Software will get more complex at Scale, and change will always happen. The question what are you doing to be more anti-fragile? Proper services require thinking and proper architecture and design principles applied at all times during a service SDLC.

  Building software at scale is tricky, and when you have lots of software, you have more problems to solve. Several times engineers look for ways to make their lives easier: make it simple, transparent, and easy to use. That sounds like a good idea, right? What can go wrong with that? Typing is never the bottleneck and will never be. We are all obsessed with reuse; several times, the reuse is marginal and brings way more problems than benefits. Working with an Object-Oriented Language such as Java makes a lot of sense to leverage Dependency. Injection and Ioc(Inversion of Control). Because it's easier to test the Application and also easier to change the Code. In the past, Spring Framework was all about XML; today, all configuration is pretty much done via Code. It's possible to use property files to configure some aspects of backend services written in Java with Spring, yes, but in reality, most of the Code is in the Code in the form of Java Spring Beans.  Spring Framework ...

Normalmente eu nao blog em português, mas hoje quero compartilhar um programa que participei recentemente. Programa gravado com o Inacio da South System sobre Arquitetura de Software, mais especificamente falando de Microservices, SOA, Shared-Libs e bem como os problemas e as soluções. Microservices estão em baixa nos dias de hoje. Porém muitas vezes não entendemos por que estamos usando microservices e nem por que estamos parando de usa-los. Muito difícil conversar sobre SOA e microservices sem falar de shared-libs e o impacto nessas arquiteturas. Nessa conversa você ira entender mais os problemas desse landscape bem como muitas alternativas para editar esses problemas. Entao bora la ver esse video! 

SOA(Service Oriented Architecture) is all about contracts. Contracts can either be managed explicitly by doing Contract First, Customer-Driven Testing, having POs manage the contract as an important asset as much as a UI is. Contracts can also be unmanaged or managed implicitly just pushing problems to consumers and making the whole org move slowly. So what is a contract anyway? Why should we care?  The contract is all Data, Behavior, and expectation involved in the services capabilities. It's easy to see just the endpoint's input and output data and forget about the rest. The rest is smaller things like data formats, access protocols, serialization formats, and do not forget about expectations. For instance let's say you are returning a list of customers, if the data is in ascending or descending order it might affect your consumer code or tests.  Contracts cab be versioned and we should have specific tests on the Implementation provider side in order to make sure we don...

Spring Boot is the most popular java stack nowadays. New languages like Go and Rust are capable of creating a single binary, self-contained with all deps to run the application. This is great for deployment simplicity but also easier to maintain. As time pass we want to have fast bootup times and do more with less. The native solutions are fast since they are statically compiled for a target platform or OS(in the case of UniKernels). Java was designed to be better as time pass(Runtime) and optimizations kick in. However thats not ideal for Serverless applications. GraalVM changes that since allowing us to compile JVM applications(Java, Scala, Kotlin) to native applications. Today I want to share a simple Video + POC using a new project called Spring Boot Native which allows us to create native images to spring boot apps.  Native images have some challenges like Type Erause for C++ and Reflections in Java. So Let's get started!

So this is the second post about monorepos. The first post was about Google Bazel, this one is about Facebook Buck . IMHO Monorepos makes all the sense for Mobile(Ios and Android) since it's all about the same application. Of course, if you have libs that can work across multiple platforms(built-in C) or similar which make sense have generic repos outside of the app monorepo. At least one app should have a monorepo. I also believe a similar strategy can be applied for SOA and Services where we could have one monorepo per business domain. In that case, we would reduce the number of microservices drastically but still work with modules. For this post, I want to share another post. We will build a monorepo with Buck and Java. Facebook Buck is very similar to google Bazel on usage and principle. So without further due Let's get started. 

So this is a hot and problematic subject: Monorepos. IMHO there are good use cases for mono repo when your project is really one thing such as angular. However, there are good use cases for microservices. IMHO we should avoid extremes and just have one big monorepo for the whole company and at the same time avoid having microservices for everything. There is a need to strike some balance between maintenance, isolation, and organization. This is the first post about the monorepos, today I will cover the solution from Google called Bazel . In the next post, I will cover the solution from Facebook called Buck. All posts will have practical videos building mono repo with Java.  IMHO the IDE integration is not ideal for both Bazel and buck. There is some support for VSCode and IDEA but is far from being ok. So Let's take a look at the video.

gRPC is a high-performance universal RPC framework. gRPC has support for interoperability between several languages such as Java, C++, C#, Go, Dart, Kotlin, NodeJS, Objective-C, PHP, Python, Ruby, Rust, and many more. gRPC has a schema for service definition and it can generate code based on that schema. gRPC also supports bi-directional streaming and authentication with HTTP/2 protocol. gRPC is battle-tested by Square, CoreOS, Cisco, CockroachLabs, Netflix, and many other companies. gRPC is also part of the CNCF project. Today I want to share a video made with gRPC and Java. So Let's get started. 

SOA it's all about Services. Services are the first-class citizen and there is no mistake in that decision. Some problems requires shared libraries and thats fine, however, I would say most of the internal shared libraries are not needed and they only cause trouble and little benefit. There is plenty of abuse of shared libraries and we need to start to recognize that we need to reduce the number of shared libraries and do fewer libraries and accept more code duplication and others from os package solutions. Shared libraries tend to spread and as a side effect, they create lots of binary coupling, complexity, and maintenance issues that kill any real Service/Microservice benefits. Services require flexibility and freedom to upgrade and release in different schedules. You might not realize but Shared Libraries are killing services and making them just a big complex distributed monolith . That's not the first time I blog about, but I still think the industry still did not get this...

Micronaut is a JVM(Java, Groovy and Kotlin) framework similar to Spring Boot or Quarkus. Micronaut is modular and blazing fast. It has a minimal memory footprint and is a bit cleaner API compared with Spring Boot for instance. Micronaut does Reflection based IOC(with Cache). Micronaut also has GraalVM support. Micronaut is a non-blocking IO and has a Reactive API based on Netty and Rectivex projects. Today I made a quick video going trought the Micronaut API DEMO I made. 

Service-Oriented Architecture( SOA ) is not new. Microservices which are a specific flavor of SOA are the default architecture you will find out in digital products. I'm not sure if Microservices will be here for much longer . However, thanks to the silicon valley, companies can be structured in 2 organizations(Which is a good thing IMHO). Product and Engineering organization. An engineering organization means that you create software for your product engineers to be more productive and focus on the product and improving the user experience. Engineering organizations have different ways they could be distributing software. Software distribution is a fascinating theme for me. There are several ways we can distribute software however we often dont consider other distribution models. As your company grows and depending on your business segment you might have several specializations insider engineering like Data Science, Security, Big Data, Architecture, Storage, Mobile Devices, and so...

Previously, I was blogging about two very HOT Button Issues ( The Death of Microservices and Why Waterfall can be better than Agile(Sometimes) . Today I want to expand and correlate these two topics a bit more. It's important to say again that I like agile, and I do it for +14 years. I have no problems talking about Agile issues. You shouldn't either. Hard questions sharpen our solutions. There is a huge difference between go trough a set of hard questions to justify investment harder than power or politics game to archive a result. The difference is one is healthy the other is not. There are "Healthy" matters like: Coupling, De-coupling, execution, Agile / Waterfall we should be able to navigate, talk, analyze trade offs without dogma or any issue whatsoever. However is hard to us to talk about some subjects right? What happens is that there is so much FEAR and TABOO on companies that some subjects cannot be ever on the table. Effective Learning means, we can talk...

It does not matter the question; the answer is Microservices Architecture(MSA). Feel that way too? Are companies doing proper microservices at all? Would it be just everybody just calling "microservices" and doing all sins against microservices? Let's adopt microservice now, okay. What problems are we trying to fix? I know I want to do it because it is everybody doing, are you sure? I think I know what I'm doing, are you? Well, "the road to hell is paved with good intentions." The problem was happening before the SOA era; we had this problem before, microservices still have it, Serverless the same. OH, this is backend thing, buddy we are good at Frontend or in BigData, DevOps Wrong! It's everywhere! If there are software and distribution, potentially, you will have this issue, which is not minor. 

Compatibility is hard. Depending on the nature of your component/service it could be very unstable by nature. Let's consider an Adapter Pattern for instance or APIs that integrate 2 other APIs, easily they will be breaking on every API change at any side. Even with mundane, regular APIs and Services, compatibility can be very hard to achieve. So, what should we do? Break all the things all the time? Be backward compatible with all versions forever(Which there are a huge price and source of complexity) or maybe there is a middle ground approach we could take? Backward compatibility is only one part of the story the whole compatibility story is much more complex involving Forward compatibility, Isolation, Interfaces, and lots of subtle details. There are the different contexts where software can live so under a microservices in one thing, shared application code is another, shared lib or company framework is completely different stories as well. IMHO at the scale, it does not matte...

Languages have trade-offs like any solution in tech. Microservices are great for many reasons, one of them allows the best tool for the job. Kubernetes allows us to have the same operational standards and procedures even using different languages and solutions. For this blog post, I want to show a simple project I build which is a constellation of services. There are 5 microservices, written in several languages like Scala, Java, Go, Python and Rust. The services do a pretty basic math operation like (+, - , / , *) and the Scala one does the aggregation and orchestrate the other services using a polish notation algorithm and REST calls.