You're designing a new system architecture. What's the most innovative solution you can think of?

The power of serverless comes from two key elements: - developers can focus primarily (not entirely) on the logic of their application and not the infrastructure it takes to make it run. This is going to get you more functionality given the same effort. - paying for only what you use. Cloud architectures have long provided for pay as you go, but the unit of scale was fairly large - typically a VM. With serverless you are paying for the CPU and memory used by a given execution through the code path. This can make things ridiculously cheap when the request volume isn't too high. Having said all that, examine your application's needs. If the requirements are complex, serverless may not be the best option.

Serverless Architecture makes sense in following scenarios: - you are a small team of engineers and don’t want to invest in infrastructure management - your team has devops mindset and willing to deal with Infrastructure as a code themselves - Application load/usage is variable hence pay per use model is cost efficient - you want to achieve faster iterations and got to market plan - Team is aware of distributed, event driven and microservices best practices - AWS and GCP provide almost full stack serverless services (cloudfront/CDN, Lambda/Cloud Run, Dynamodb/Firestore, glue jobs/dataflow, Redshift/BigQuery)

In envisioning a groundbreaking system architecture, one of the most innovative solutions is leveraging Docker containers. Docker introduces a packaging format that neatly bundles an application's code and dependencies into a standardized format. This empowers the application to launch swiftly and reliably across diverse computing environments. Docker containers, renowned for their lightweight and self-sufficient nature, encapsulate all essentials for running an application, including libraries, system tools, code, and the runtime environment. Beyond being an executable unit, Docker is a comprehensive software platform enabling developers to expedite the creation, testing, and deployment of containerized applications.

I hope that by now, creating a micro-service application is not considered "innovative" anymore, nor event-driven, arguably serverless since its the more recent trend of the three. Innovation comes from how you combine these principles to solve real-world issues. These three concepts are indeed pretty much tied together and working hand in hand to achieve architectural and operational excellence: breaking down your software into small re-usable components (micro-services, mostly), that you run serverless, embracing infrastructure as code, and have them communicate asynchronously via events and commands will give you the most flexible and evolutive foundations for your future product.

Observability platform is key to highly agile and demanding solution, where issues are understood and actionable insights are provided to the engineers.

We should never start designing a system with pre-determined solutions. As engineers, we need to understand that technology is just a tool to deliver business value. Deciding which particular approach should be taken while designing a system depends on the business problem we are trying to solve versus the trade-offs we are ready to make. All the patterns mentioned have their pros and cons. To identify which one needs to be implemented, we need to first identify the problem we are trying to solve. Having said that, I assume most of the industry-standard complex enterprise problems can be well handled with event-driven, cloud-native solutions with maximum open-source technologies.

Serverless Architecture supports much better scalability, and much better turn around time when it comes to scaling up (or down) especially if the platform utilization changes seasonally. The serverless architecture also provides better economies of scale and therefore marginal cost of scaling up is much lower and you can easily scale down w/o wasting capital spent on server hardware by letting it sit idle. It’s also much easier to set up geo-redundancy and disaster-recovery options, in the serverless architecture.

This is a given in any solution, especially for organizations that are buckling up for a disruptive growth. Since the focus must be on customer problems and retention, the debt from managing servers should be reduced.

Serverless architecture enables running code without managing servers, cutting costs, enhancing scalability, and streamlining development. Cloud platforms like AWS Lambda, Google Cloud Functions, or Azure Functions execute code in response to events such as HTTP requests or database changes. Ideal for applications with sporadic demand or requiring integration with various services.

There is no "best" one. There is the most suitable one for the application's needs. The choice of architecture depends on what we need to deliver. We need to have knowledge of all standards and services available on the market and have the discernment to apply the most appropriate one to each situation.

Microservices are great to let full-stack teams individually develop their solutions without interfering unnecessarily. Challenges arise if - the problem is broken down into too many services => orchestration of the services becomes difficult - development effort is changing => developers have to change between teams => learning new technology when boarding a new team So make sure to build mirco services, not nano services. You also might want to limit the autonomy of teams regarding their technology choices to limit the on-boarding efforts when changing teams.

O que acho fundamental em uma arquitetura de micro serviços é padronização de stack, que leva a: 1. Reuso de componentes 2. Sistemas eficientes de apoio as pessoas de engenharia / devtools 3. Viabiliza escalar novas squads com mínimo tempo de onboarding Já experimentei ambientes com múltiplas tecnologias e a dificuldade de escala se materializa de forma frequente, como por exemplo (1) pipelines complexas (2) gestão de vulnerabilidade difícil (3) onboarding de novos colaboradores ineficiente. Não duvido que para usos específicos deve ser observada novas tecnologia, mas para um percentual grande de micro serviços da mesma empresa é viável a padronização com ganhos no cycle time e reuso.

It is much easier to maintain and validate code and functions in a microservices architecture. It also reduces regression testing and improves your ability to deploy software changes quickly. It also provide a better structured modular approach to built functions and services.

Microservices architecture divides applications into small, independent services communicating via APIs, enhancing agility, reliability, and performance while enabling continuous delivery. Different technologies, languages, and frameworks can be used for each service, ideal for complex or evolving business logic and horizontal scaling.

Microservices, in a nutshell, implement an architecture where a big application is broken into smaller sub applications(known as microservice), each having their own dedicated servers on which they are hosted, and quite often their very own database as well It comes in handy when we have a very large application with multiple functional components and we have a team having particular expertise in each of those components. Each team/team member can have ownership of a single microservice. A single microservice can be scaled, maintained and changed independently without directly affecting any other microservice. Each microservice can be language agnostic as well. One can be in NodeJS, the other can be in Python, etc

It's a misunderstanding to think, that microservices communicate with what most people assume to be APIs. Instead the communication between microservices has to be asynchronous, and event based. At the core of a microservice system is a messaging system, like e.g. Apache Kafka. That's how that architecture was meant. This will give you 1. responsiveness - no service ever waits for responses, and hence never blocks. 2. hot failover - when one instance of a service breaks, all the others just keep processing events. 3. scalability - just shard a type of events, and distribute the load that way.

One innovative solution in system architecture design is the implementation of microservices. This approach involves breaking down a complex application into smaller, independent services that can be developed, deployed, and scaled individually. This allows for greater flexibility, resilience, and scalability compared to monolithic architectures.

Designing a new system architecture offers the opportunity to embrace innovative solutions that can lead to significant benefits in terms of performance, scalability, flexibility and security. An innovative solution that could be considered is the adoption of a microservices architecture. I wanted to think of something new and more innovative, something radical, but I couldn't and I limited myself to microservices. Microservices architecture is an architectural approach that breaks down an application into a series of modular, independent services, each of which performs a specific function within the application. Each service is autonomous, scalable and can be developed, deployed and managed independently from other services.

Microservice architecture is a system design style that divides a complex application into smaller, independent services that communicate via APIs. Some benefits are: Modularity: easier to understand, maintain, and reuse components Agility: faster to adapt, deliver, and deploy changes Scalability: better to handle varying loads and performance Diversity: more freedom to choose technologies and platforms. Some drawbacks are: Complexity: harder to manage a distributed system Cold start: slower to invoke services after inactivity Vendor lock-in: less portability and interoperability Debugging and testing: more difficult to monitor and troubleshoot Security and compliance: more exposure to risks and issues.

Microservices architecture promotes functional decomposition for modularity and easy maintenance, enabling independent development, deployment, and technological diversity per service. It enhances resilience, as single service failures do not affect the entire application, and supports scalable service architecture. Best practices involve aligning services with business capabilities, utilizing CI/CD, preferring asynchronous communication, centralizing configuration management, and implementing effective monitoring. Key technologies include Docker, Kubernetes, API gateways like Kong, service meshes such as Istio, development frameworks (e.g., Spring Boot), and monitoring tools (Prometheus, Grafana).

Usually requires some experience but help to build infra that reacts to your events like: running routines, do quick security checks and reporting. Example, one of your IAM users just changed Prod DB secret. Can lead to a disaster, right? Right, but if you have an alerting system you can easily react, fix and prevent.

We've developed products like ASNGW for WiMAX using Model Driven Architecture (MDA), relying on Event Driven Architecture (EDA). This same architectural concept is very well suited for Autonomous AI Agents. These agents await for events from humans or other agents to execute tasks collaboratively, prioritising tasks through a priority queue for efficient message handling. Expanding on this architecture, each agent can feature ports for receiving events from various sources (perception), enabling diverse actions. This extension provides: Ease in managing agents across various configurations (parallel, sequential, aggregation, hierarchical, and dynamic creation). The capability to integrate perception/timer messages asynchronously.

Event-Driven Architecture (EDA) is defined by event-triggered actions, decoupling, and asynchronicity, fostering system responsiveness and agility. Best practices include employing a pub/sub model, CQRS for separating command and query management, and event sourcing for state persistence. Tools like Apache Kafka, Axon, and Apache Flink support message brokering, event management, and data streaming. EDA benefits include enhanced responsiveness and adaptability but pose challenges like design complexity and data consistency management.

Event-driven architecture allows us to perform specific actions based on alerts triggered by events. We have implemented this method in our environment to resolve any major issues promptly.

Event-driven architecture is a good but selective approach in a system design style that uses events to trigger and communicate between decoupled services or components. Some +ve points are: Responsiveness: faster and real-time reactions to events Scalability: easier to handle varying loads and performance Agility: more flexibility and innovation to adapt to changes Connectivity: better integration and interoperability of systems. Some -ve points are: Complexity: harder to manage a distributed and asynchronous system Testing and debugging: more difficult to monitor and troubleshoot the system Security and compliance: more exposure to risks and issues Vendor lock-in: less portability and choice of platforms and services

Event-driven architecture utilizes events to trigger and coordinate system components' actions, enhancing responsiveness, flexibility, and scalability while reducing dependencies. Events represent changes in system state or data, such as user actions or system errors. Patterns like publish-subscribe or event sourcing can be employed to implement this architecture, ideal for asynchronous or real-time applications processing large data volumes.

Event-driven architecture leverages events—messages indicating state changes or system data updates—to orchestrate component interactions, enhancing system responsiveness, flexibility, and scalability. This approach minimizes component coupling and dependencies. Implementing patterns like publish-subscribe, event sourcing, or CQRS facilitates this architecture, making it optimal for applications requiring asynchronous communication, real-time interactions, or the handling of substantial data volumes. Event-driven architecture supports dynamic, data-intensive environments, enabling efficient and adaptive system designs.

Core Concept: In an EDA, applications don't directly call each other. They publish events and subscribe to events Benefits: Decoupling: Services are loosely coupled, meaning they don't rely on each other's internal structure or implementation. Scalability: Individual services can be scaled independently based on their needs without impacting others. Resilience: If one service fails, other services can continue operating based on the events they've received. Real-time processing: Events can trigger immediate reactions, enabling near real-time responsiveness. Components: Event producers: Services that publish events; Event channel/broker: A central component and routes events to consumers. Event consumers: Services that subscribe to events

Microservices won't work for you without an event driven architecture. Those two are the same. In a way it fees strange, that architecture patterns are still considered innovative, that we've already been using over a decade ago. That ain't innovative.

Si bien los modelos enumerados en el artículo pueden parecer excluyentes, no son arquitecturas aisladas. El manejo de eventos, a través de publicaciones de “endpoints”, presenta la opción de ejecución de rutinas por microservicios bajo condiciones muy específicas, evitando la saturación de rutinas de ejecución continuas que dificultan la supervisión además de despilfarrar recursos. Por ejemplo, un servicio de integración de plantillas no necesita estar chequeando periódicamente una carpeta de entrada, en su lugar puede haber un servicio de Datafactory “escuchando” por webhook la llegada del archivo al momento de cargarse en un almacén blob de Storage (plataforma Azure). Es el modo más eficiente de ejecución.

Reactive architecture emphasizes responsiveness, resilience, and elasticity, ensuring systems rapidly respond to user interactions, withstand failures through component isolation and replication, and dynamically manage resources. It employs asynchronous communication, reducing coupling and enhancing scalability. Tools like Akka, Vert.x, and Spring Reactor support these principles, offering concurrent, distributed, and non-blocking application development. Key patterns include the actor model, functional reactive programming, and backpressure to handle data flow and control. Benefits include improved performance, scalability, robustness against failures, and flexible adaptation to changes, promoting efficient, reliable, and agile systems.

Reactive architecture is a design approach that emphasizes responsiveness, resilience, and elasticity in software systems. It's built on principles such as asynchronous message passing, event-driven programming, and the ability to handle high concurrency and unpredictable workloads. Reactive systems are designed to react to changes in the environment, scale dynamically, and maintain responsiveness even under heavy loads. This architectural style is particularly well-suited for modern applications that require real-time processing, low latency, and high availability, such as those in fintech, IoT, and online gaming industries.

The challenge is to find ways of extending and improving what's possible on existing SAAS and PAAS platforms using current software languages. Event-driven architecture already exists and can be leveraged on the platforms I'm most familiar with. We look for ways of responding to those events, whether they be across the platform or between platforms. We create frameworks and services to process events, handle send errors, errors where the receiving component doesn't respond to an event, and other situations important to an application. We're creating new patterns that ideally will work to extend existing architecture patterns where compatibility exists. E.G. daisy-chain events to respond to other events or with future patterns.

Adapts quickly to production demand, as it is important to respond to needs as they evolve. Even if we must consider that IT equipment evolves very quickly, it is important to have a long-term view.

Reactive architecture, extending from event-driven principles, prioritizes resilience, elasticity, responsiveness, and message-driven systems. It gracefully handles failures, fluctuations, and latencies while optimizing resource utilization and user experience. Utilizing tools like Akka, Vert.x, or Spring Reactor, reactive applications employ non-blocking, asynchronous, and distributed programming models. Ideal for high-concurrency, high-availability, or performance-demanding applications, as well as those operating in dynamic or unpredictable environments.

Reactive Architecture represents a paradigm shift in how we design and build scalable applications, offering numerous benefits that align well with the demands of modern, responsive systems. When implemented through frameworks like Quarkus, this architectural style enhances an application's resilience, elasticity, and responsiveness, fundamentally changing how it handles workload and data flow. Elasticity is a big hallmark of Reactive Architecture, allowing systems to scale up or down with demand. Quarkus facilitates this by enabling lightweight, isolated services that can be independently scaled, providing a more cost-effective and responsive scaling strategy compared to traditional monolithic architecture

Reactive architecture, an extension of event-driven principles, focuses on creating systems that are resilient, elastic, responsive, and message-driven. This approach enables systems to gracefully manage failures, fluctuations, and latencies while optimizing resources and user experiences. Tools like Akka, Vert.x, and Spring Reactor support the development of reactive applications through non-blocking, asynchronous, and distributed programming models. Ideal for applications requiring high concurrency, availability, or performance, reactive architecture thrives in dynamic or unpredictable environments, offering a robust solution for modern system demands.

Characteristics of reactive architecture: Responsive: The system prioritizes responsiveness, ensuring timely handling of requests. Resilient: It gracefully handles failures and recovers quickly from disruptions. Elastic: The system can easily scale up or down based on changing workloads. Message-driven: Components communicate asynchronously using messages. Benefits: Improved user experience; Increased fault tolerance: The system can gracefully handle failures without impacting overall functionality. Enhanced scalability: The system can easily adapt to changing workloads, making it cost-effective and efficient. Simplified development and maintenance: Loose coupling promotes modularity, making the system easier to develop, maintain, and test.

Reactive architecture is very similar to event driven architecture, and hence also to microservices - the way, they're actually meant to be. In many cases you can consider them interchangeable, because the differences are more kind of which of the aspects you emphasize, not so much about real differences.

Die Stabilität einer Architekturen ist besonders wichtig, insbesondere in sicherheitskritischen oder etablierten Umgebungen. Gleichzeitig ist es jedoch auch relevant, strategisch auf neue Technologien zuzugehen, um die Entwicklung nicht zu verpassen. In bestimmten Branchen und Szenarien kann ein gewisses Maß an Innovation erforderlich sein, um wettbewerbsfähig zu bleiben oder neue Chancen zu nutzen. Die richtige Balance zwischen bewährten Lösungen und innovativen Ansätzen zu finden, ist daher entscheidend.

Data is not born in the data-center, as such it important to consider techniques from distributed intelligence (Federated Learning, Split Learning / horizontal or vertical setting) to learn from those devices in cases where data on the edge is generated too fast to transfer centrally.

Imagine processing happening right where the data is generated, like having a mini data center on your doorstep. The power of edge computing: - Low-latency applications. - High-bandwidth data streams. - Data privacy-sensitive applications. The future of system architecture is distributed, and edge computing is at the forefront!

Interactivity needs close loop reactions, so the sensors actuators loop should be running in edge computing while system management could be done in the cloud. In this example it is really latency and then bandwidth for the sensor fusion which drives towards this distributed solution. Edge computing could be also a way to distribute some mathematical or calculation power and be resilient to failures and disasters.

Edge computing brings computation and data processing closer to data sources, at the network's edge, enhancing efficiency by reducing latency, bandwidth usage, and costs while boosting security and privacy. Utilizing devices like sensors and smartphones for tasks such as data analytics or machine learning, edge computing supports applications requiring low latency, high bandwidth, sensitive data handling, or operation in remote or offline environments, offering a tailored, responsive solution to modern computational challenges.

Edge computing enables us to collect and analyze a lot of data in our daily lives and send it to the cloud using wearable devices. It is an interim solution to connect devices to the cloud through the network.

Edge computing model is processing data closer to its source, on devices or servers at the "edge" of the network. This offers several advantages: Reduced latency: Processing happens closer to the data, enabling real-time applications and faster response times. Improved bandwidth efficiency: Less data needs to travel long distances, freeing up bandwidth for other critical tasks. Enhanced offline functionality: Edge devices can make decisions and function even without constant connection to the central server. Increased security: Sensitive data can be processed locally, reducing the risk of breaches during transmission.

Die Einführung von Edge-Computing bedeutet oft eine komplexe Implementierung, hohe Anschaffungskosten für die benötigte Hardware und die Notwendigkeit einer stabilen Netzwerkverbindung. Die damit verbundenen Vorteile lassen sich erst im Anschluss vollständig nutzen.

Edge computing can be powerful but it can have greater security concerns both in terms of hardware exposure (for IoT solutions in particular) as well as data security in the forms of financial, PII, etc that also need to be taken into account. Greater emphasis on threat assessments is a must.

Edge Computing ou computação de borda, pode ser entendido como um paradigma de processamento de dados em que o processamento ocorre mais próximo da fonte dos dados, diferente do modelo tradicional de processamento centralizado em nuvem. Isso significa que parte ou a totalidade do processamento de dados ocorre em dispositivos locais, como sensores, dispositivos IoT (Internet of Things), gateways e servidores próximos ao local de geração dos dados. deve se analisar de forma atenta as vantagens e desvantagens da computação de borda:

Choosing the right system architecture is more about alignment with business needs than chasing innovation. It's crucial to understand the product's nature and requirements. For instance, simplicity and cost-effectiveness in low-transaction environments might outweigh the benefits of adopting serverless computing. Often, adapting proven solutions with minor adjustments can offer the most value. While innovation has its place, it also brings risks, especially in cost and implementation timelines. In many cases, a well-established architecture might be the optimal choice, ensuring reliability and scalability without unnecessary complexity. #SystemArchitecture #SimplicityInDesign

Innovation in architecture is typically wrong. Sometimes a breakthrough is possible, but more often you end up with something that is needlessly complex and complexity is the death of large software systems in the long run.

The last thing you want to do when designing system architecture is be innovative. Innovation is what you reach for in exceptional cases. For instance, it's what you reach for when you are looking to find a new business niche involving disruption of existing businesses. When building a system architecture, innovation is what you reach for only when existing solutions don't work or don't scale. Well known, boring, and requiring skills available in the market place is how you build system architecture. I didn't think LinkedIn would lure me into posting on one of these. Heh.

Don't think about innovation; think about business. Don't try to predict; you will be wrong anyway. Build a simple but scalable system. Please don't believe it when they say not to count the money; you should always know how much it costs to support your architecture.

Being a software architect is more than building the most innovative solution. It's about building the most suitable solution for the given set of requirements. There are countless innovative technologies and methods out there, and as an architect, I'd love to implement each. Cell-based architectures, Right-Sized Services, and Serverless are some examples of innovations that have their place. But as architects, we need to remember that these tools are meant to solve a certain type of problem. If all you have is a hammer, everything looks like a nail. Architects should have a diverse toolset at their disposal, including old and new techniques. The key is choosing the correct tool for your use case.

It gives me shivers to read “the most innovative architecture” without any hint at what the system is supposed to do. Architecture and technology are an answer to the business requirements, functional, not functional, and economical. Picking an architecture “because it is modern” is going to lead to disaster. To be really innovative the architecture should be well thought out, with data driven decisions, balanced to the need, and built with no pre-conceptions. You do not see those often.

Designing a groundbreaking system architecture requires an approach that pushes the boundaries of innovation. Leveraging cutting-edge technologies such as artificial intelligence and blockchain, the proposed solution integrates decentralized computing paradigms with adaptive learning algorithms to create a self-optimizing, autonomous system. By harnessing the power of distributed ledgers and machine learning, this architecture not only ensures unparalleled scalability and fault tolerance but also continuously evolves and adapts to changing environments and requirements.

The best way to think about Software Architecture is based on balance. For every real-life use-case where a systemic solution can be built, one must assess the balance point between expected outcome and effort involved. In these cases, the most innovative solution may not be related to the technology, platform, programming language, cloud-native, or anything else. The balance between technology, effort, time, and outcome (and outcome here is the solution to the real problem) can deliver innovation to the business without forcing the introduction of modern technologies just because they are modern. For innovation, tech hype must be a driver and not a requirement. This is a way but not the only.

Above all, optimize your architecture for short dev work loops (code, test, repeat). I sometimes think modern developers, especially web app devs, must have no idea just how productive web app developers once could be. Forget hot module reloading (HMR), prior to WebPack and modern transpilation, Chrome devtools workspaces would load and reflect changes in source files instantly with no reload, and even let you edit source files without leaving Chrome. A Jenkins box could create PR builds and host them in minutes, allowing fellow team members (designers, PMs, managers, devs) to quickly review. Short feedback loops between developers and others can increase velocity by an order of magnitude or more over multi-day feedback loops.

Ok so I was at a MACH summit recently and as much serverless is in demand , the need to have a middle ground is gaining cognisance. This is albeit a journey so while solutioning it’s recommended to understand the devops need and involve them from all POC stages. Despite this it’s getting eventually stiff to say which model is effective. So suggest to understand the dynamics and then collectively agree on the trade offs.