Designing Resilient Architectures for the Cloud and AI Era: A Conversation with Gabriel Baptista and Francesco Abbruzzese

An educator and Azure PaaS specialist joins forces with the creator of MVC/Blazor toolkits to unpack AI-ready architectures, cloud-native patterns, and the evolving role of software architects in .NET

From AI-assisted code generation to designing for edge computing and zero-downtime deployments, software architecture today demands fluency across disciplines. In this conversation, we speak with Gabriel Baptista and Francesco Abbruzzese—co-authors of Software Architecture with C# 12 and .NET 8—about how cloud-native and distributed systems are reshaping enterprise applications, where AI fits into architectural workflows, and why adaptability, not complexity, should guide long-term design decisions.

Gabriel Baptista has been working with software development since the early days of .NET. Today, he specializes in Azure Platform-as-a-Service (PaaS) solutions, teaches at computing engineering universities, and mentors tech startups across industries. Francesco Abbruzzese is the creator of the MVC Controls Toolkit and the Blazor Controls Toolkit. His career spans decision support systems for finance, top-selling video games, and over two decades of advocacy for Microsoft’s web stack. Together, they bring deep experience in enterprise systems, modern DevOps practices, and real-world architecture challenges.

Their book, Software Architecture with C# 12 and .NET 8, now in its fourth edition, translates high-level design theory into practical guidance for the .NET ecosystem. Covering everything from microservices and DevOps pipelines to design patterns, observability, and Kubernetes-ready architectures, the book is anchored by a detailed case study that walks readers through building an enterprise travel agency system from the ground up.

You can watch the full interview below—or read on for the complete transcript.

---

1: What inspired you to write Software Architecture with C# 12 and .NET 8?

Francesco Abbruzzese:
Yes. The main point was that this book collects various subjects that are hard to find together in the same place. I wrote it mainly to put everything into something solid—a book—to capture my experience in one place. It’s also a useful tool for my job, for my advisory work, for my courses, and for my customers.

Gabriel Lara Baptista:
Well, to me, it was a really important milestone in my career—because writing a book is no small thing, right? I’ve been working in academia and in the industry for a long time, and this was a great opportunity to give back to the community. Like Francesco said, it’s a complete pipeline on how to create an enterprise solution, and that was really exciting.

There’s a big value in having the opportunity to write something like that. Today, I can use the book, as Francesco does, for teaching and in my current career—it’s something I can actually apply. So I really enjoyed the experience. It was a great opportunity to work with Francesco because we share a lot of common ground, and I think readers will see that in the book. It might look like it’s written by a single person, but we’ve worked together for a long time. It’s been a great collaboration.

Francesco Abbruzzese:
It was a pleasure for me too, Gabriel.

2: AI is transforming pretty much everything in the tech landscape. Could you share some examples of how AI-driven tools are currently being used in architectural design, and what new paradigms you see emerging from AI’s influence in this space?

Gabriel Lara Baptista:
Yeah, well, AI is the most talked-about topic in every discussion right now. What I think we, as architects, need to understand is that a good AI solution first requires a good software architecture—because AI only works with good data. Without good data, you cannot have a good AI.

As architects, we’ll be impacted by AI—positively or negatively—depending on how we work with it. Let me give two examples. Today, it's possible to upload an architecture diagram into an AI tool like ChatGPT and discuss with it whether you’re creating a good or bad design. That’s already possible. In some cases, I’ve used AI to give me feedback or suggest changes to my designs. It can do that.

But as a software architect, you still need to be a good analyst. You need to evaluate whether the output from the AI is actually correct. Especially in enterprise systems, that’s not always easy to do. So, yes, AI will change the world, but we—as individuals—need to use our intelligence to critically analyze whether the AI output is good or not, in any context.

As software architects, we need to understand that we have to build architectures that will support good AI—because if you don’t provide quality data, you won’t get quality AI. What do you think, Francesco?

Francesco Abbruzzese:
OK. I think AI is a valuable tool, but at least for now, it can’t completely replace the experience of a professional.

It helps save time. It can suggest choices—but sometimes those suggestions are wrong. Other times, those suggestions can be useful as a starting point for further investigation. AI can write some code, some diagrams, some designs that you might use as a base. That saves time.

Sometimes it suggests something you hadn’t thought of, or reminds you of a possibility you forgot to consider. That doesn’t mean it’s the best solution—but it’s a helpful suggestion. It’s a tool to avoid missing things and to save time.

At the moment, AI can’t replace the experience of a real professional—whether it’s an architect, a programmer, or someone else. For instance, I’ve never seen AI come up with a completely new algorithm. If you have to invent a new one, it’s not capable of doing that.

So yes, AI is a helpful tool—it helps save time and make sure you’re not overlooking something. But that’s all. There isn’t much more to say about it.

Francesco Abbruzzese:
And I think this won’t change much over time—at least not until we reach actual artificial general intelligence, something human-like.

3: How can architects effectively use AI to enhance rather than replace their roles in software architecture?

Francesco Abbruzzese:
OK. I’ve already addressed this a bit, because architects should use AI to save time—to write down some starting designs or starter code. For instance, in my company, we developed an AI tool that, through interaction with the architect, is able to generate a complete Visual Studio solution—with all the required projects—and some initial code.

Of course, that code doesn’t always work perfectly, but it’s a good starting point. It saves time compared to creating the entire solution manually, which usually takes a lot of time—especially if you're using complex architectures like the Clean Architecture or the main microservices architecture. These require solutions to be organized in a complex way, with many projects involved.

AI can help save time by generating most of the initial code. You can then modify it as needed, but even so, it can reduce the groundwork by 50 to 60 percent.

There’s no real risk of AI replacing us, because the hardest part is still modeling the real world—and at the moment, AI doesn’t have enough experience or understanding of the world to do that on its own. It needs a human to explain the requirements. We’re still quite far from AI being able to do everything without human help.

Gabriel Lara Baptista:
Yeah. Our book specifically discusses the role of the software architect in an enterprise team. As a software architect, you design the pipeline and solutions for the entire team. You’re responsible for the technical aspects of designing enterprise solutions.

Right now, AI can be used to accelerate processes—not just for the software architect but for the entire team. But I totally agree with Francesco: AI today is mostly helpful as a starting point. You still need a human to judge whether that output fits the actual requirements of the enterprise solution.

Especially in enterprise systems, the need for high-quality work is critical. Within a team, you’ll have junior developers, senior developers, analysts—and AI tools, especially those that assist with coding, can help all of them. Not just by generating code, which is often just the beginning, but by analyzing whether you’re following best practices in your code. We already have copilots that assist with that.

So, as a software architect, you need to evaluate whether these tools are right for your team—whether they help improve the team’s output and velocity. That’s where AI can play a supporting role: helping the architect define the team’s development pipeline.

4: According to you, what specific architectural practices should be adopted to ensure cloud-native systems are resilient and adaptable?

Gabriel Lara Baptista:
First, it’s important to say that in the near future, I believe most applications will be cloud-native. I agree that some applications still need to run on the edge, but it’s almost impossible not to have at least something running in the cloud to support those edge-based systems. This is something that everyone working in software development today needs to think about.

When it comes to building resilient and adaptable software—well, our book covers this topic in depth. We have several chapters that talk about resilience, writing good code, and adaptability—especially because the speed of development today is much higher than it was a few years ago.

We’re discovering new ways to build solutions every single day. We can’t always keep up that same pace on the architecture side, which is why we need to think carefully about how to design a software architecture that can be both adaptable and resilient.

We also need to account for non-functional requirements like security, performance, and—most importantly—resilience. One of the most critical factors is that applications can no longer afford downtime, especially enterprise applications that need to run 24/7.

To achieve that, you need to write good code—code that provides visibility into what’s happening, that integrates with retries, that enables better performance. A software architect has to consider these things from the very beginning—right when they start analyzing the application’s requirements.

Francesco Abbruzzese:
OK. In my opinion, it’s quite simple—cloud computing basically means distributed computing, with added adaptability. It allows you to change your hardware dynamically.

Cloud computing is really about reliability and adaptability. But you have to use the right architecture—that means applying the theory behind modern microservices and cloud-native systems.

I’m talking about reliable communication, orchestrators like Kubernetes, and automatic scaling—these are all provided by cloud platforms and also by Kubernetes itself. You also have tools for collecting metrics and adjusting the software’s behavior automatically based on those metrics. This is the essence of the theory we’re dealing with.

For example, in microservices architectures, reliable communication is essential. These applications are often structured like assembly lines—processing and transferring data step by step. That means it’s unacceptable to lose data. Communication must at least eventually succeed. It can be delayed, but it has to succeed.

There are many techniques and even formal theorems for reliable communication and for understanding what guarantees you can expect. The theory behind distributed computing and microservices is quite advanced at this point. You can find a lot of the basics and starting points in our book.

5: Considering the sophistication of modern cyber threats, how can security by design principles be integrated throughout the architecture?

Francesco Abbruzzese:
OK, it’s a good question. First, you have to understand that security by design isn’t a separate subject—it’s just a way of doing architecture and code, keeping security in mind while designing and coding.

So, the main answer is: education. You have to study the right way to do things, and avoid inventing untested or improbable solutions. You also need to choose the right team members—that’s a major factor.

That said, some tools can help. In my opinion, the best tool is code review—having a security expert review the code to identify potential vulnerabilities and ensure best practices are being followed.

Another important tool is using existing stacks and libraries that are already designed with security in mind—tools that follow best practices. Avoid inventing your own methods for things like authentication. There are already reliable, tested libraries available for that.

So, in my opinion, the three main pillars are: education, code reviews, and using existing secure libraries and frameworks.

Gabriel Lara Baptista:
Yeah, I totally agree with Francesco. I’d just like to complement his answer by expanding a bit on the three areas he mentioned.

First, education. A software architect needs to study information security. For example, OWASP provides a list of the top ten vulnerabilities you might encounter in your APIs. A software architect needs to be aware of these to prevent code that introduces such risks.

Second, when it comes to code review—think about DevOps. Instead of just implementing DevOps, why not implement DevSecOps? With DevSecOps, you can include static analysis tools that identify security issues early. These tools help architects and senior developers review the code produced by the team and ensure security practices are being followed.

Third, we need to be cautious when choosing libraries. One of the most critical security issues is using outdated or vulnerable libraries. So, as Francesco said, it’s essential to choose libraries that are secure and well-maintained.

6: What strategies do you think architects should employ to ensure long-term architectural integrity?

Gabriel Lara Baptista:
Well, architecture is not immutable—you can and should change it. It’s a living thing most of the time.

But if you design it with the principles we’ve been talking about—like security by design, reliability, adaptability, and monitoring—you’ll be in a much better position. These principles help you recognize when you’re hitting limitations and when the architecture needs to evolve.

I don’t believe you should start with the most complex architecture possible. In my opinion, you should begin with something simple. Most software, even enterprise software, doesn’t require an overly complex architecture to start with.

Start simple, and continually monitor and analyze whether you're hitting bottlenecks or facing challenges. That way, you can evolve your architecture gradually. This is especially easy with cloud technologies, where scaling or adjusting an application is much faster compared to on-premises systems.

Also, you need a strong pipeline—one that helps you understand the requirements, implement good code, perform thorough code reviews, run proper testing, and gradually deploy to production. Even if the application itself is simple, a solid pipeline ensures the architecture remains healthy over time.

Francesco Abbruzzese:
Yes. I completely agree—the main points are using the cloud, because it allows you to easily change the architecture, and monitoring your application so you can detect when requirements or conditions have changed.

Also, it's important to understand the requirements clearly and choose the best-fitting architecture. The better your initial architectural choice, the longer it will remain valid.

Let me add one more point. In my opinion, it’s very important to use techniques like Domain-Driven Design and microservices. These approaches allow you to make localized changes to your architecture without affecting the whole system. This makes your architecture easier to modify over time.

For example, each microservice can follow its own architectural approach if needed. You can update or tune just a small part of the system. This flexibility really helps with long-term architectural integrity.

Gabriel Lara Baptista:
Let me just add one thing, as Francesco said. When we implement applications using Domain-Driven Design, we can’t forget about design patterns. These patterns—whether at the code level or architectural level—make applications more extensible.

When Francesco talks about Domain-Driven Design with microservices, that’s a pattern. Why not implement a pattern that’s already widely adopted and proven? It makes things simpler. That’s why I mentioned earlier that simplicity is key.

7: How do you envision the evolution of enterprise application architecture with the integration of things like edge computing and increased data centricity? What kind of industry-specific impacts do you think these changes could have?

Francesco Abbruzzese:
OK. Collecting peripheral data and using all available data for decision-making—that’s definitely the future, no doubt about it. Applications will absolutely have to be implemented with this in mind.

But on one hand, we have the need to keep data separated. You mentioned data-driven design—each microservice should be responsible for its own data. There are also geographic constraints and other concerns that make data separation necessary.

On the other hand, we want to take advantage of all the available data. So what does this mean? It means we need a special kind of microservice—worker microservices that consolidate data. These services take peripheral data from different sources and consolidate it to feed decision-making processes.

This kind of data consolidation—supported by AI or statistical techniques—will become a central aspect of future applications. I can’t say for sure which technique will become dominant, but the key point is: we need to consolidate data in the right format and with the right level of detail for it to be useful. That’s what matters most.

Gabriel Lara Baptista:
I’d complement Francesco’s answer by saying that edge computing will impact every industry in the future—there’s no industry that won’t need it. Edge computing enables decision-making at the point of data collection, and that decision is often powered by AI.

The decision might happen at the edge, but the results of that decision need to be sent to a central location or data store. That’s why the future of application architecture will be entirely distributed. And because of that, the principles Francesco mentioned—Domain-Driven Design and microservices—will be even more important. Future applications will need to be distributed by design.

We’ll also need to think about how to collect and consolidate all that edge data. And it’s important to understand that we don’t need to send all the raw data—just the decisions or critical insights. That’s a very important distinction when designing edge applications.

So, yes, distributed solutions will become necessary for every industry.

Q: Gabriel, how do you see technological advancements—both current and future—altering career paths in software architecture? What new skills do you think are becoming essential for professional growth?

Gabriel Lara Baptista:
Technically speaking, based on everything we’ve discussed so far, understanding how to design and implement distributed applications is essential. Whether we’re talking about microservices, serverless, or something else—at the core, we’re dealing with distributed systems. And that’s where the world is headed.

So, in the near future, anyone pursuing a career in software architecture will need a strong foundation in distributed computing. Information security is another critical area. And, of course, AI—we’ve mentioned it at several points today. Those three—distributed computing, security, and AI—are the technical pillars moving forward.

But there’s also another key aspect: soft skills. Architects need them. Whether you're implementing a DevOps pipeline, building a secure SaaS platform, or introducing observability, those changes will affect the entire team. To lead those changes successfully, you need to bring the team along with you. And soft skills will make that possible.

8: How can architects ensure their designs effectively contribute to business outcomes—especially in industries where the impact of technology is significant?

Francesco Abbruzzese:
OK. The key is making sure our work—our architecture and our design—adds value to the business. That’s the main point.

The best tool for this is DevOps. DevOps is designed specifically to align technical outcomes with business goals.

But I’ll say more. It’s also about collecting metrics, so you can see how your application is performing and where improvements are needed. And it’s about creating architectures that are easy to adapt. We already talked about this earlier—so again, Domain-Driven Design and microservices are essential.

If your architecture is based on these principles, you can modify individual parts easily. You don’t have to rewrite large portions of the application. You can identify the specific part that needs to change in order to deliver more value to the business.

Also, we need a different approach to gathering requirements. Instead of just collecting what the user says they want, we need to think about the business value behind each request. This mindset shift is similar to what we do with security by design. Every requirement we collect should be evaluated in terms of the value it adds to the business.

So for me, there are three key components: DevOps, Domain-Driven Design with microservices, and a value-oriented mindset from the very beginning of the requirement-gathering phase.

Gabriel Lara Baptista:
As Francesco said, DevOps is the answer.

Why is the answer DevOps?

Because with DevOps, you have the possibility to collect information in a small period of time about the evolution of the application. And then you have the feedback that gives you the opportunity to design the application better for the near future—
for the next cycle of DevOps.

Architecture, by concept, is the idea of implementing something that makes things easier to adapt and to maintain. So if you have a good architecture, it’s going to be easier to adapt for new functionalities that you may have or to maintain, if you have something wrong.

So with good architecture, you give space for the business team to define better solutions. And you’re going to have a faster feedback loop, and you're going to adapt the application faster. And you're going to give more value to the business.

So it’s a good cycle when you have DevOps well implemented, together with a good architectural design because you're going to happily increase the value of the solution that you are developing.

---

To explore the topics covered in this conversation in greater depth—including building scalable enterprise systems with microservices, applying architectural patterns like Domain-Driven Design, and preparing .NET applications for Kubernetes and cloud-native deployments—check out Software Architecture with C# 12 and .NET 8 by Gabriel Baptista and Francesco Abbruzzese, available from Packt. Now in its fourth edition, the book combines design fundamentals with hands-on .NET practices, covering everything from EF Core and DevOps pipelines to Blazor, OpenTelemetry, and a complete case study centered on a real-world travel agency system.

Here is what some readers have said: