Diego Pacheco Tech blog

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. 

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. 

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? 

Every company has a legacy code. Often we confuse legacy with multiple different concepts, and this confusion makes improvements harder to happen. Most engineers don’t like to deal with legacy code-we all like shiny new things. Unfortunately, most of the time, there is no easy way out. It is possible to replace a legacy system with a brand new system because it is easier and faster than fixing all the legacy’s problems. We can’t get out of legacy systems because they have old languages, old databases, and often messy. Is that so? However, there are 2 kinds of old languages. The ones who are dying and dated like Delphi or Clipper and the other ones are old but are perfectly fine to use C++ or Java. I’m not defending legacy systems; however, I believe several essential aspects need to be considered. Old: Mature vs. Dated Commonly, we confuse mature software with dated.  Boring technology  is full of good arguments there. Old technology not necessarily means it is terrible. ...

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! 

Design is not Subjective! I know we have bad actors out there and several times people do Bad Design and use subjectiveness as a way to control the dialog and shut down conversations. Today I want to explore more why I believe design is not subjective and Design is done by Design. Design is about Goals, Purpose, and Structure. Decisions are driven considering a particular problem Domain and thats an important matter. When we do design without considering a domain we often step into a code problem, not into a design problem. Just looking at the code misses the point and ends up killing the design. Today I want to share a slidecast I made going deeper on these questions and hopefully I will be able to demonstrate to you why Design is not subjective at all or at least why it should not be. Let's get started!

Micro frontends were highly inspired by Microservices. So why not extend the same benefits from microservices to micro frontends, right? Things are a bit easier at the backend because we can actually have proper and real isolation . Meaning process/machine isolation, since we can distribute workloads in different machines. When we are looking into micro frontends is not the same deal. We also need to remember that microservices were highly inspired by SOA and Microservices are a flavor of SOA. Microservices are DEAD and in decline for the Backend, so it's interesting to see it's a major trend for the frontend. At the end of the day the Browser architecture did not change much and in the backend is much easier to have isolations and we have different flavors of isolations like Docker , UniKernels , MicroWorkers , etc... 

This is the first slide-cast for Architecture and Engineering: Doing the non-obvious. This slide-cast was inspired by the Management: Doing the non-obvious series ( I and II ). For this slidecast, I will cover some non-traditional and non-obvious vision and philosophy about Engineering and Software Architecture. I also will recommend +20 books so you can improve and also get more insights. Buckle up, I will challenge several traditional and established ideas. So I hope you guys like it - Let's get started! The Video The Slides Architecture & Engineering: Doing the non-obvious! de Diego Pacheco Cheers, Diego Pacheco

I had experiences where every single service had to be a ticket with an architect document in order to be able to start using every new technology or service. So every engineer hates to work like that. I personally dont think thats the why to roll because thats means that process wins.  Netflix is famous to have a culture where they threaten people like grown-ups. So if you have grown-ups why do you need to review every single thing people do all the time? For sure reviews are a good thing but architects as Gate Keepers are not a good thing. In general Gate Keepers(DevOps Engineers) as well is as bad as Arch as Gate Keepers. I have mixed feelings but personally, I dont think there is value in having Gate Keepers which is a very poor solution and IMHO a poor usage of people's times. So Why gate Keepers exist? 

Software architecture it's much more than satisfying requirements. Requirements can be tricky and several times misleading. Requirements are easy answers and they often shut down important discovery processes. Requirements are old as snakes, they were heavily praised by RUP, CMMI, PMI and still in vogue nowadays. The requirements list is just a wish list someone made. Requirements gave the false sensation of doing the right thing but this is just a lie. Requirements are often lying. Software architecture is a continuous process that requires thinking, judgment, leadership, and critique. Requirements are some easy to be gamed and often they are. So why people do it? Well, I think thats the wrong question. Software is full of sudo-science being used for ages and just does not work like estimates for instance. 

Services are a thing for a long time in the backend. +20 years I would say. Microservices are much newer however they also started the backend. Micro Frontends is a very hot topic in frontend engineering right now. Frontend engineering evolved a lot in the last 5 years. Ui are becoming more and more complex and frontend teams are growing a lot. With complexity and growth, we stumble into classical backend problems such as Teams Organization and Scalability and the need for Isolation as a base for Independence and increase the number of deploys. Frontend technology evolves much faster than backend. With all that comes debit and believe me or not the difficult to find people to work on old tech like AngularJS. 

SOA has the right principles for scalability with cohesion and consistency. Microservices are dying nowadays for several reasons like  Lack of Isolation , Distributed Monolith & Shared Libs Abuse , and many other reasons such as the wrong boundaries. I deeply believe we need to double down in Services and SOA . Sometimes the Sidecar Pattern also makes sense and is an interesting approach .  However, there are times where we really need to go to Internal Shared Libraries.  When that's the case we can still apply SOA for Internal Shared Libraries and have a better a clean design such as having a clean CORE . Keep in mind there is a lot of shared libs abuse in companies but in the cases where internal shared libs are the right choice, there are some important considerations. SOA can philosophy can help internal shared libs to do better and by doing so we can have better solutions with much fewer headaches. I need to repeat Internal Shared Libs should not be your goto ap...

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

So this is 3rd part of the series of BFF Dilemma. If you did not read part 1 and part 2 I highly recommend read them before continuing with this one. GraphQL is a kind of BFF I would say. BFFs then to be more flexible and allow all sorts of programming models and techniques. GraphQL is Data-Driven and has fewer options in a sense of flexibility. However, GraphQL is an interesting solution that could be used as a BFF solution or in conjunction with a standard BFF solution. Several people wonder if GraphQL is the natural replacement of REST. There are all sorts of comparisons with SOAP vs REST vs GraphQL. IMHO GraphQL is not the REST replacement I would not expose APIs only with GraphQL ONLY for all sorts of reasons. 

Previously I was blogging about the BFF dilemma . I want to continue to explore the subject because I find it very interesting and I believe they're still a lot of things to explore on the subject. BFFs are super popular nowadays, for several reasons, mainly I would because of the nature of modern products.  If you have a digital product is very likely you will need to ship your problem in at Least 3 platforms (Web, Ios, Android) somethings even more platforms and specialized devices like TVs, Tablets, IoT, Arduinos and much more. Also, microservices were a big force pushing for BFFs since the services are "micro" and code need to live somewhere. It's really interesting when we think about them since we have so many options and places where our code can live. 

The software industry is always becoming more specialized. We have backend engineers, frontend engineers, edge engineers, cloud/DevOps engineers and I'm sure we will have more specialization in the future. With specialization and growth on systems, we end up having more layers or places that we can put software. Microservices often end up making a huge proliferation of services at the backend(check out Uber case for that).  There are so many places that you can "put" your software but one particular place that is growing a lot is the BFF(Backend for Frontend)  place. Often we have different stacks for backend and frontend. Frontend often is on JavaScript or TypeScript. Backend is often in Java, .NET or Go. So the first dilemma is, is BFF a frontend thing or a backend thing? IMHO it's a frontend thing where frontend means consumer. So how different BFF is from a driver or client? Well if you look into drivers and clients they often dont have network logic like routing,...

Software Design is a super important discipline. However, Design is often made by accident. Software Design is really needed because there is a huge cost associated with some changes further down when you have a scale and lots of software. Lots of engineers dont understand design or understand it on a superficial level. Software design is on the core of everything we do in software and I believe we need to talk bout this super important discipline. So I made a slidecast talking about the subject. Let's get started. 

There are several architectural patterns we can follow when we need to distribute a shared piece of software. My favorite and default pattern is Service Pattern. However, there are other patterns for software distribution.  If we think about startups for instance there is a popular tool called Lean business Canvas where you model the business model of your startup and there are many dimensions there but one particular dimension called "Distribution Channels" is highly related to the subject of this blog post. We, as engineers often just think about one dimension with is either a Service or Binary shared library.  However, there are other dimensions we could explore. The other options are Tooling, Internal Services / Self-Service Platforms, Runtime Platforms, and Service Mesh. So for this blog post, I want to cover a little bit more the Sidecar Pattern. 

Software Design it's a huge sub-set of Software Architecture. Software design is really about the domain and the designer. Good design takes time to make and it's not a one-size-fits-all solution. In order to have a good design, you need someone who first of all cares about design and study design a lot. In order to improve as a Designer you need to:  * Write code  * Read code (a lot)  * Think about responsibilities  * Think about bringing things together  * Think about braking things apart * Do and participate in Design Sessions  * Time and Experience  There are several schools out there like Services, OOP, FP, and many others. IMHO there are some CORE ideas that we can use besides your language, school of thought, and experience.  Knowing what not to do is as much important as knowing what to do. For this blog post, I want to talk more about CORE Design.

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