Microservices Design & Architecture
Tuesday, October 26, 2021
We went from a single monolith to a set of microservices that are small, lightweight, and easy to implement. Microservices enable reusability, make it easier to change and scale apps on demand but they also introduce new problems. How do microservices interact with each other toward a common goal? How do you figure out what went wrong when a business process composed of several microservices fails? Should there be a central orchestrator controlling all interactions between services or should each service work independently, in a loosely coupled way, and only interact through shared events? In this talk, we’ll explore the Choreography vs Orchestration question and see demos of some of the tools that can help.
Too often we encounter the idea that software architecture is an esoteric concept, of which only the chosen ones, and at the right time, are allowed to discuss. Well, how about a little change of perspective? With software development and users' needs evolving so fast, we don’t afford the luxury of rewriting systems from scratch just because teams fail to understand what they are building. Today’s software developers are tomorrow's architects. We must challenge them to step away from the IDE and understand how the architecture evolves in order to create a common and stable ground in terms of quality, performance, reliability, and scalability. At the same time, software architects need to step away from the abstractions and stay updated to the project development reality. This session revolves around finding the right ways of intertwining up-front architecture, API design & coding while maintaining a continuous focus on architecture evolution.
Adoption of Service Mesh is rising and deploying Service Mesh on multiple clusters (on premise, in the cloud, in different clouds, ...) is becoming a standard requirement. But it's also introducing new challenges: - how to ensure each service has a unique identity across the clusters - how to secure the communications between the clusters - how to manage RBAC globally In this talk, I'll focus on Istio and show how to overcome these challenges. I'll introduce SPIFFE and explain how to use trust domains and service accounts to ensure a unique identity globally. I'll also demonstrate how service discovery can be performed natively or using a third party solution, how to simplify cross cluster communications and allow service failover. Finally, I'll cover how a global RBAC can be put in place."
PRO WORKSHOP (MICROSERVICES): What Are Service Mesh Features That Can Secure Your GraphQL Gateway Platform?Join on Hopin
With service mesh, you can secure graphql gateway requirements such as authorization, authentication, ingress, egress, service to service communication, and workload isolation. Those are default service mesh features that you don't have to code or implement. Additionally, using EnvoyFilter for graphql fine-grained authorization ensures that data is provided to allowed consumers only.
PRO WORKSHOP (MICROSERVICES): Out with the Old “Lift and Shift” - New Techniques for Modernizing Legacy Apps for Cloud NativeJoin on Hopin
Modernizing legacy applications is a critical element of enterprise digital transformation today. Without enhancing technology, technical debt becomes too costly to maintain causing customer and business interruptions and leaving a company increasingly vulnerable to the competition. Enterprises who have tried to lift-and-shift their monolithic applications are often disappointed with their results because “lift and shift” methods don’t allow for enterprises to take full advantage of the value cloud brings. It’s not until a business has refactored their legacy applications into microservices that the true benefits of the cloud can be realized. In this session, Moti Rafalin, CEO and Co-founder of vFunction, will present the four key benefits of moving legacy applications to a cloud native architecture (increased business agility, lower costs, improved scalability and accelerated engineering velocity), and introduce new techniques and best practices to accelerate the app modernization process and a company’s journey to cloud native architecture. This technical workshop will also include insights into how architects and developers can leverage advances in dynamic analysis, data science, and graph theory to advance microservice architecture refactoring to accelerate and refine the decomposition of monolithic applications into microservices.
Automation is inherent to microservices and container orchestration. Security? Not so much. Container security continues to lag behind in organizations' rush into cloud native modernization, with little security automation usually in place beyond vulnerability scanning and the occasional security policy "suggestion." This session will review the limitations of eBPF-centric security, make clear why it is limited for automating behavioral-based security policies, and demonstrate how to fully automate (hands-off!) behavioral detection, policy creation, and multi-cluster deployment of zero-trust perimeters using NeuVector's patented and unique approach to the growing challenge. Get this right, and you'll be able to automatically detect -- and even prevent -- anomalous activities and zero-day exploits.
Wednesday, October 27, 2021
The software we write does not always work as smoothly as we would like. In order to know if something went wrong, understand the root cause, and fix the problem, we need to monitor our system and get alerts whenever issues pop up. There are many useful tools and practices for Kubernetes-based applications. As we adopt serverless architecture can we continue to use the same practice? Unfortunately, the answer is no.In this session we will discuss: The differences between monitoring Kubernetes and serverless based applicationsBest practices for serverless monitoringMethods to efficiently troubleshoot serverless based applications Join our session and start enjoying the great benefits of serverless computing.
Wix has a huge scale of traffic. more than 500 billion HTTP requests and more than 1.5 billion Kafka business events per day. This talk goes through 3 Caching Patterns that are used by Wix's 2000 microservices in order to provide the best experience for Wix users along with saving costs and increasing availability. A cache will reduce latency, by avoiding the need of a costly query to a DB, a HTTP request to a Wix servicer, or a 3rd-party service. It will reduce the needed scale to service these costly requests. It will also improve reliability, by making sure some data can be returned even if aforementioned DB or 3rd-party service are currently unavailable. The patterns include: * Configuration Data Cache - persisted locally or to S3 * HTTP Reverse Proxy Caching - using Varnish Cache * (Dynamo)DB+CDC based Cache and more - for unlimited capacity with continuously updating LRU cache on top each pattern is optimal for other use cases, but all allow to reduce costs and gain performance and resilience.
There are many advantages to using GraphQL as an API for your frontend, however building a GraphQL server that provides security guarantees, serves entities from your database or other microservices can be very tedious and error prone.By using Hasura, we can start leveraging the power of GraphQL and provide a secure and robust API the can easily connect with our backends and DB.In this talk, I'll provide a short intro to GraphQL, present how we usually build GraphQL servers with tools such Apollo, and then show how this former process can be simplified significantly with Hasura.Afterwards, we'll dive into some of Hasura's advanced features such as row-column permissions, remote joins, actions - that supercharge your GraphQL capabilities. We'll share how we use it internally at Livecycle as our main backend-for-frontend that provides us with much greater control of the security and flexibility for complex data management.
Yes, you read it correctly. When I first heard this sentence I didn't get it too. But when I looked back on all the systems I've seen start as small and simple and become a monstrous legacy I realized that not being able to adapt to changes in requirements was the cause.In this talk, I will explain how to create and implement an architecture that is structured around the volatilities of the solution and not its functional requirements.We will talk about a methodological approach to building such an architecture and some tips and guidelines on how to implement this architecture in a real-life NodeJS project
Thursday, October 28, 2021
Microservices are hard. There is a huge premium to be paid in order to leverage the benefits this architectural paradigm brings along. With domain driven design at the heart of Microservices, different bounded contexts cooperate to accomplish a business process. Two important questions arise - Is my process working fine? if not why is it failing? In this talk we will explore the concept of "Observability". Why is it important and how often it's one of the most neglected aspects while designing a Microservices ecosystem.
Managing dozens or hundreds of distributed services and microservices on a scale can be very challenging. As developers, we are often blind to how our application behaves in production and the areas we need to check to find and prevent issues early on in the development process, before deploying new versions. In this talk, we’ll show you how to leverage the open-source OpenTelemetry to collect and analyze the relevant data from production, and how to use it pre-production, during development and testing phases, to improve your code quality and overall success in preventing issues before deployment.By relying on production behavior, we can automatically generate more efficient tests, catch dependencies that are about to break in real life, and have our developers more productive & product-oriented.
The food wastage in India is 70 tonnes per year, and there is mismanagement at several layers. Approximately 20-30% of the wastage happens in the last mile, between wholesale traders, and retail mom-and-pop stores. Is there something we can do about food wastage ? This was the problem statement I attempted to solve as a first engineering hire at a startup. Our customers were 12.8 million retail owners that deal in FMCG (Fast-moving consumer goods, such as food grains, tooth paste, etc.). The goal was to develop a platform for retail traders (mom and pop shop owners / small and medium business owners) to buy FMCG products from wholesale traders using an Android app.We were attacking a deeply entrenched business practice to help solve a societal goal. For a section of the population which is not very well versed with smartphones and technology, the user experience had to be designed from the ground up to be multi-lingual, fungible, unstructured, and relevant. In this talk, I cover how we went about iterating the solution from a simple SMS based system to a full fledged app backed by micro-services. Having a micro-service architecture provided us the agility to experiment and iterate quickly, and we were able to push out changes much faster, and help solve wastage problems even sooner. I will discuss how we laid out the micro services with separation of concerns. I will discuss the several problems we faced in this segment with regards to unstructured data, and how our data models in the micro-services had to adapt. We used cloud services extensively, so I will also cover how different pieces came together in a cogent form to build better experience for our customers. After having worked in bigger companies on software projects that scale to millions of devices, this was a unique challenge for me, and something I am very proud of. I would like to share my experience in building empathetic micro services based software for the masses
Lecture + Demo What are federated microservices? Federated microservices are independently deployable components of a federated application. In a federated application, components are loaded from multiple network locations and repositories at runtime. They are not developed by a single team or built from a single codebase. Multiple federated application components can run in a single application instance, and can be redeployed at any time, without restarting the application or interrupting other components that happen to be running Why are federated microservices needed? Incidentally, the word “federation” accurately describes the structure of the development organization microservices enables: one made up of small, independent teams with internal autonomy. Let’s consider what provides this autonomy and what role distributed systems architecture or simply “distribution” plays. What is the purpose of distribution in a microservices architecture: scalability, polyglossia, deployment independence? Itenables all three. But which properties are indispensable to the kind of organization we want to support? If we conflate concurrency of users with concurrency of developers, we could say scalability is essential. But in the proper sense of the term, you can also scale a monolith. (Consider Facebook.) Polyglossia opens up the potential developer pool and language fitness for purpose. But what makes each team able to innovate at their own pace without being dependent on the activities of the others? Clearly, its deployment independence. So while distribution may make it easier to scale, scalability is not a reason for implementing microservices. You don’t abandon your monolith because it doesn’t scale, at least in the traditional sense of that word. You abandon it because lack of modularity and proper organization has rendered the codebase brittle and difficult to change or augment as business requirements evolve or your organization grows. The main reason for distribution is deployment independence. Without it, teams have to coordinate their releases and new features may have to wait. It’s what allows teams to work at their own pace of innovation and the business to evolve with speed and alacrity. (You get polyglossia for your trouble). The problem is that distribution increases complexity, and not insignificantly. While it ensures modularity, as every component is now isolated by a hard-and-fast boundary: the network; it makes component interactions harder to develop and the system as a whole harder to manage. What was previously an in-memory function call is now a network call. An entirely new set of circumstances apply. The application will take longer to code and will be harder to test and deploy. Test and deployment automation are absolutely required. Performance will be slower. Troubleshooting will be more difficult, et cetera. All of this raises the barrier to entry for organizations looking to benefit, not from distribution, but from deployment independence. Up to this point, putting up with the microservice premium, as its known, was simply considered a trade-off, not a problem with a potential solution. (Although the solution is commonly mentioned in descriptions of the problem.) The result is a disproportionately high degree of failed implementations, missed opportunity for those forewarned of failure, and growing operational complexity. Consider the “death star” effect or big ball of mud. Let's see how federated applications might solve these problems, with technologies such as: self-deployment, distributed object caching, transparent integration, and module federation.
JSON web tokens are a stateless portable secure identity transfer format. In this talk, we'll discuss how you can use JWTs to secure your microservices, what signing protocols make sense, and how to handle revocation.
Service mesh has been a great solution to resolve some of the issues introduced by the microservice architecture by providing service to service tracing, security, client-side routing, and more, but every company is different, thus a need for the extra mile service-to-service communication customization. In this talk we will explore how to customize the communication between services using webassembly and envoy: - Quick Introduction to webassembly and envo - Building a webassembly filter - Deploying a web webassembly filter between multiple services- Debugging a webassembly filter