IT training white paper modernization why the actor model matters khotailieu

WHITE PAPER Modernization: The End Of The Heavyweight Era Why The Actor Model Matters for Cloud Infrastructure Table of Contents Why Read This Report Key Takeaways Java EE Middleware is the Wrong Approach for Today’s Cloud-Based Infrastructures Distributed, Reactive Systems Unlock Higher Cloud ROI .3 Java EE Middleware Is A Modernization Mismatch Java EE complexity leads to low development velocity and infrequent releases Java EE is too heavyweight to scale, and too expensive for the cloud .5 Java EE won’t let you harness ‘data in motion’ Shifting Towards Actor-based Reactive Systems Design distributed systems based on Reactive principles Take a lesson from Domain Driven Design (DDD) Prioritize resilience before thinking about elastic scaling in the cloud 11 Utilize actors for native distribution, concurrency, supervision, and resilience 12 Modernizing with the Actor Model .13 Enhancing customer engagement with data-driven insights 14 Unleashing innovation to protect or capture markets .14 Improving agility and time to value 15 Reducing compute costs while scaling elastically 15 Increasing developer happiness and productivity 16 The Days Of Java EE Heavyweight Middleware Are Ending 17 MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE Why Read This Report Key Takeaways In a world where business models face constant disruption, digital business imperatives are driving architects and technology leaders to embrace modernization to remain competitive However, traditional application monoliths running on Java EE middleware were not designed with development agility and cloud elasticity in mind, making them an ill-suited solution for today’s needs Java EE Middleware is the Wrong Approach for Today’s Cloud-Based Infrastructures This report helps architects and technology leaders understand the business impact of modernizing with the actor model to build Reactive systems systems that are purpose-built for the modern era of multicore cloud computing Over the years, the use of legacy technologies and expensive Java EE middleware has resulted in the pervasiveness of large, monolithic applications Enterprises are becoming bogged down with long release cycles and increasingly complex applications, leaving teams unable to achieve a high level of development productivity as well as firefighting production systems that were never designed for cloud infrastructures Distributed, Reactive Systems Unlock Higher Cloud ROI Achieving ROI in the cloud starts with designing distributed architectures and decomposing monoliths into individual, decoupled microservices based on Reactive principles Reactive systems enable enterprises to be flexible able to adapt to complex environments and quickly roll out new changes without rigid dependencies and coordination With the actor model as a foundation, these systems are designed to scale massively at any given moment without compromising infrastructure Most importantly, they are capable of rapidly identifying, reporting, and self-healing in the face of failure at any system level MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE Java EE Middleware Is A Modernization Mismatch “By 2019, fewer than 35% of all new business applications will be deployed in Java EE application servers.” - Anne Thomas, Distinguished Analyst at Gartner Group Global 5000 enterprises that never before considered themselves as technology companies are now faced with digital business imperatives that force them to modernize their infrastructure On the path to becoming a digital, on-demand provider, speed is the ultimate competitive advantage With technology and business innovation inextricably intertwined, businesses must adapt with greater agility than ever before Technology leaders (e.g Amazon, Microsoft, Google, LinkedIn, etc.) and industry analysts (Gartner, Forrester Research, RedMonk) agree that modern system architecture must embrace a cloud-first strategy to capture the benefits of development agility and cost efficiency Modern systems need to be optimized for latency and architected for resilience and elasticity As online consumption continues to grow at an exponential rate, modern systems require a highly flexible infrastructure design that can scale at levels far higher than previous conceptions of peak traffic For the majority of use cases, however, the Global 5000 not have the luxury of starting with a greenfield infrastructure such as digital natives LinkedIn, Netflix, or Airbnb Changes need to be made within existing frameworks to keep pace with new web scale organizations Yet most organizations have huge investments in legacy Java EE infrastructure, resulting in technical debt and monolithic systems that require modernization in order to reverse the following: • Poor development agility that causes slow and infrequent releases • Monolithic applications that are difficult to scale and aren’t optimized for cloud infrastructure • The inability to react based on real-time insights and streaming ‘data in motion’ Java EE complexity leads to low development velocity and infrequent releases For a decade or more, enterprise development teams have built their Java EE projects inside large, monolithic application server containers without much regard to the individual lifecycle of their module or component Hooking into startup and shutdown events was simple, as accessing other components was just an injected instance away It was comparably easy to map objects into single relational databases or connect to other systems via messaging One of the greatest advantages of this architecture was transactionality, which was synchronous, easy to implement, and simple to visualize and monitor Projects were released twice per year, had multi-year lifespans, multi-month test cycles, and large teams to manage everything MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE But those days are now at an end Due to lack of agility, applications grew enormous, leading to the accumulation of technical debt, slower development velocity, and longer release cycles ›› Development team agility is constantly blocked With no simple development model to sup- port modern systems, the traditional compile-build-deploy cycle for every service cripples productivity At best, reusability and componentization in Java EE is achieved by sharing packaged bundles between projects These designs ultimately rely on a single database schema with sheer project ROI calculated on comparably long production uptimes ›› Big teams and heavy apps create long release cycles With ongoing maintenance and the con- stant addition of new features, monoliths constantly grow in size This means that each app has to be created, maintained, and managed by increasingly larger project teams Team structures are also heavily influenced by these monolithic software architectures, with multi-month test cycles being perhaps the most visible proof Projects with lifespans longer than five years tend to have huge bugs and feature databases Since containerless development is impossible, testing is barely qualified there are no acceptance tests and hardly any written business requirements or identifiable domains in design and usability ›› Complex code bases and fearful engineers lead to technical debt Instead of business-driven components, the classical monolith has a very technical design and struggles to keep up with the constant change in business requirements Production releases often occur only twice a year, and introducing new features or making hot fixes outside of the official production setting process is a risky venture Upholding the motto: “Never change a running system,” continuous inherited complexity leads to a very cautious update process by engineers who are understandably afraid of breaking anything And as technical debt increases, enterprises are discovering that licensing models of various vendors force them to continue use of older product versions Java EE is too heavyweight to scale, and too expensive for the cloud From a production perspective, the classical monolith relies on heavyweight infrastructure and rarely scales inside the application server itself Scaling therefore requires vast engineering resources, making it a clunky, expensive, and inefficient process ›› Monoliths are difficult and expensive to scale Java EE applications are bound to the thread- per-request model, making it difficult for them to scale to larger numbers of servers And clustering relies on vendor-specific features because it’s not part of the Java EE specification Servicing a growing number of users requires the complete replication of the application server stack, including the underlying infrastructure With more extensive scaling requirements, the use of vendor-proprietary features and clustering options is mandatory for many installations MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE ›› Monoliths lead to resource inefficiency Even with optimizations, scalability is limited to a couple of hundred nodes and can’t be controlled dynamically to serve load peaks without confronting failures Instead of intelligent, dynamic scaling, monoliths must always be prepared for traffic peaks This makes scaling and calculating infrastructure requirements difficult, leading to a lot of unused compute power that is only activated for rare high demand occasions And when things go wrong, Java EE has no built-in resilience mechanisms one component failure usually brings down the entire application Java EE won’t let you harness ‘data in motion’ Since its invention, the way people use the internet has fundamentally changed A tidal wave of connected devices, sensors, and intelligent home appliances has caused demands to grow exponentially In 1995, less than 1% of the world population had an internet connection Today it’s around 40% The number of internet users increased tenfold from 1999 to 2013 The world’s billionth user logged on in 2005, and by 2010, that number had doubled to two billion In 2014, the internet reached three billion users (source: http://www.internetlivestats.com/internet-users/) In response to this rampant growth, the requirements for modern applications have drastically changed ›› Java EE is not built for Fast Data Instead of operating on data that rests in a centralized relational database (RDBMS), modern software increasingly relies on data in near real-time While there will continue to be a need for batch-mode processing for some services, the ability to work with time-sensitive data presents an enormous competitive business advantage Yet Java EE has no native support for streaming “data in motion,” and the tools provided (JDBC and JPA) are synchronous and blocking, allowing only one query at a time per connection MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE ›› Java EE lacks flexibility to move fast Modern reporting and incident analysis has to happen while the data streams into the application, not in retrospective With high flexibility now a requirement rather than a “nice to have,” production systems must be equipped to resolve issues that weren’t considered or even relevant when their initial version was put into production MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE Shifting Towards Actor-based Reactive Systems “The actor model [is seeing] renewed interest as cloud concurrency challenges grow.” - Jeffrey Hammond, Principal Analyst at Forrester Research To address all the shortcomings of monolithic Java EE applications and the heavyweight middleware and infrastructure needed to run them, developers must shift their thinking Both systems and organizations themselves must increase flexibility, adapt to complex environments, quickly roll out new changes without rigid dependencies and coordination, know how and when to behave in certain ways, scale massively at any given moment without compromising infrastructure, and most importantly, be able to rapidly identify, isolate, and self-heal in the face of failure at any level The steps for achieving these goals include: Design distributed systems based on Reactive principles On the path to Microservices, take a lesson from Domain Driven Design (DDD) Prioritize resilience before thinking about scaling elastically in the cloud Utilize the proven actor model to achieve native distribution, concurrency, supervision, and resilience Design distributed systems based on Reactive principles Designers need to build systems for flexibility and resiliency, not just efficiency and robustness This necessitates the redesign of existing Java EE applications into more flexible modules that are self-contained, autonomous, and can be scaled independently, as they are responsible for their own business context from individual features down to the relevant data These are called Reactive systems To make it easier for business leaders, IT professionals, and third-party vendors to innovate and collaborate around these new systems, a common vocabulary was established in the Reactive Manifesto1 to cover these requirements: Reactive systems are Message-Driven, Resilient, Elastic, and Responsive 1  Spearheaded in 2013 by Lightbend CTO/Co-founder and the inventor of Akka, Jonas Bonér, the Reactive Manifesto has been signed by over 15,000 people and translated into 11 languages MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE Value Form Means responsive elastic resilient message-driven ›› Message-driven means more than just non-blocking I/O Reactive systems at their foundation are powered by asynchronous, non-blocking, message-driven communication This enables supervision, isolation, and replication of failed processes ›› Resilience goes further than fault tolerance The ability to self-heal in an automated and predictable way is treated as part of the full service/application lifecycle and made possible by a message-driven approach to communication ›› Elasticity means efficient, cost-conscious scalability A message-driven foundation enables a level of indirection and loose coupling This helps create systems that can boost performance by scaling out, as well as up, across all physical and cloud infrastructure during busy times, and lower costs by dynamically scaling in/down during slow times ›› Responsive systems always serve customers Reactive systems provide a consistently responsive user experience that is highly available, never fails during busy times, and isn’t susceptible to blocked processes and cascading failures Take a lesson from Domain Driven Design (DDD) Rather than thinking of Microservices Architecture (MSA) as service-oriented architecture (SOA) 2.0, developers now have the Reactive Manifesto to help them apply the principles of Reactive systems to real world domains The requirements of MSA can best be identified with the help of Domain Driven Design MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE (DDD), an architectural principle that recommends designing systems to reflect real world domains, considering the elements, behavior, and interactions between business domains Microservices operate on principles similar to those of DDD Each microservice owns its data and must be responsible for a specific feature or functionality, and be able to work together as a system to form an aggregation of cohesive functionality A good rule of thumb is to gather services that change for the same reason while separating those services that can change for a different reason This can be achieved by designing systems that: ›› Use encapsulation to improve flexibility Microservices must encapsulate all internal imple- mentation details so that external systems utilizing them in the cloud or on-premise never need to worry about the internals Encapsulation reduces complexity and enhances flexibility of the system, making it more amenable to changes ›› Apply loose coupling to avoid the cascade effect The changes to a single microservice should have no negative impact on other services As synchronous communication introduces a host of interrelated dependencies, this principle aligns with the message-driven communication approach to distributed systems by enforcing asynchronous, non-blocking communication between microservices As per SOA, RESTful APIs are more suitable than Java RMI, as the latter enforces a technology on other system components ›› Separate domains of concern to reduce complexity Creating microservices based on distinct functions with zero overlap of concerns with other components lets designers reduce the complexity of interaction between services While it is important for each microservice to own its data, there is considerable flexibility in how that data is stored Of course, the data may be stored in a traditional database However, it is also common for some microservice implementations to store data into multiple databases For example, store data in an RDB for flexible queries and also in MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 10 ElasticSearch to provide more advanced search options Another common data storage approach is to save all data change requests in an event log and also store the data in a more queryable form in one or more databases This approach is known as Event Sourcing and CQRS (Command Query Responsibility Segregation) The advantage here is that these other data storage options offer greater flexibility for how data is stored and how it can be retrieved These alternatives provide much more flexibility for scaling and resilience Prioritize resilience before thinking about elastic scaling in the cloud Most applications are designed and developed for blue skies But all software across all time has failed and will continue to fail Today’s applications therefore must be designed with the inevitability of failure in mind With cloud-based microservices architectures, things are even more complex: these applications are composed of a large number of individual services, adding a level of complexity that touches all relevant parts of an application in order to measure availability and recover from failures These new requirements force designers to reconsider how they incorporate error handling and fault tolerance into applications Modern applications must be resilient on all levels, not just a few Reactive systems therefore place a critical focus on resilience, which enables systems to self-heal automatically and adopt a “let It crash” philosophy The key to achieving this is message-driven service interaction, which automatically provides the core building blocks that enable systems to be resilient against failures at many different levels In turn, these building blocks serve as a rock-solid foundation that is capable of scaling in and out elastically across all system resources ›› Automate supervision to minimize human intervention The goal for design of resilience against failures is to minimize human intervention Supervision the ability to identify successful or unsuccessful task completion across the entire system is at the core of system performance, endurance, and security Supervision based on a message-driven approach enables location transparency, so that processes can run and interact on completely different cluster nodes as easily as in-process on the same VM ›› Isolate and contain failures to enable self-healing When isolation is in place, systems can separate different types of work based on a number of factors, like the risk of failure, performance characteristics, CPU and memory usage, etc Failure in one isolated component won’t impact the responsiveness of the overall system and the failing component will have a chance to heal A dedicated separate error channel allows redirection of an error rather than just throwing it back to the caller ›› Master resilience and elasticity to achieve system responsiveness Modern applications must be resilient at their core in order to scale and remain responsive under a variety of real-world, less than ideal conditions The result is a consistently responsive system ready for business MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 11 Utilize actors for native distribution, concurrency, supervision, and resilience Traditional “sometimes asynchronous” platforms like Java EE are missing a key requirement for building distributed systems Microservices architectures must be message-driven and distributed from the start, from the lowest level protocols extending out into third-party APIs and scaling elastically across clusters Distribution is not something that can be added on later, but is a critical, foundational design element that must be in place from the beginning Enter the actor model First conceived in 1973 by Carl Hewitt, the actor model is a message-driven approach to concurrent computation intending to provide “the prospect of highly parallel computing machines consisting of dozens, hundreds, or even thousands of independent microprocessors, each with its own local memory and communications processor, communicating via a high-performance communications network.” (William Clinger (June 1981) “Foundations of Actor Semantics” Mathematics Doctoral Dissertation MIT.) MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 12 Modernizing with the Actor Model “For the first time in our history, we faced no downtime on Black Friday.” - Walmart Akka is an actor-based message-driven runtime for managing concurrency, elasticity, and resilience on the JVM with support for both Java and Scala By applying the proven actor model to the JVM, Akka is distributed by default to serve the evolved needs of microservices architectures, providing distribution, concurrency, supervision, and resilience Critically, Akka allows designers to: ›› Focus on the business logic, not low-level protocols Not only developers need to be able to take advantage of multiple cores on a single machine, at a certain point they must also utilize clusters of machines themselves Distributed by default and based on the proven actor model, Akka provides managed concurrency out-of-the-box so that teams can focus on the system’s business logic rather than manually wiring together complex, low-level protocols ›› Eliminate bottlenecks and single points of failure Reactive applications are difficult to build within thread-based frameworks because of how hard it is to scale out an application reliably based on shared mutable state, threads, and locks When designed incorrectly, system performance and availability suffer huge losses Akka actors employ asynchronous, non-blocking, message-driven communication with a secure supervision model This allows Akka to easily share work across all infrastructure resources, resulting highly resilient, elastically scalable systems ›› Realize true ROI from investing in cloud infrastructure Shared mutable state also makes it difficult, though not impossible, to scale up Ensuring thread safety is complicated, and performance penalties associated with over-engineering for thread safety are severe With the lightweight actor model, Akka is ideal for cloud and hybrid-cloud deployments, keeping infrastructure costs under control while maintaining a high level of responsiveness to serve customers To address the business challenges of modernization, many of the most admired brands around the globe are transforming their businesses with Lightbend, engaging billions of users every day through software that is disrupting their markets Lightbend provides the leading Reactive application development platform on the JVM for building distributed applications and modernizing aging infrastructures Using microservices and fast data on a message-driven runtime, Reactive Platform applications are able to scale effortlessly on multicore and cloud computing architectures, avoiding many common Java EE pitfalls MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 13 Supporting both Java and Scala, Lightbend Platforms include the Akka message-driven runtime, Lagom microservice framework, Play web framework, and Scala programming language With Lightbend, development teams can deliver highly responsive user experiences backed by a resilient, message-driven application stack Enhancing customer engagement with data-driven insights For many enterprises, using data-driven insights to deepen customer engagement over web, mobile and IoT applications is a focal point of digital transformation Consequently, architectures are shifting from batch to streaming ›› Microservice and data architectures are unifying The demands for availability, scalability, and resilience is forcing Fast Data architectures to become like microservice architectures Conversely, successful organizations building microservices find their data needs grow with their organization Hence, there is a unification happening between data and microservice architectures that the actor model is uniquely capable of serving ›› Case Study: Delivering 30-second personalized offers at 100x traffic peaks At online gaming leader William Hill, personalized offers may only be valid for thirty seconds and must perform perfectly when traffic regularly spikes by 100x READ MORE Unleashing innovation to protect or capture markets Many digital transformation initiatives at large enterprises are being sparked by either The Innovator’s Dilemma in which market leader successes and capabilities have actually become obstacles to seizing the next wave of innovation, or the Reinventors in which successful companies are using a key asset to capture a new market ›› Empowering developers to innovate Lightbend technologies based on the actor model make developers feel empowered by making things that used to be very hard quite easy and straightforward, allowing them to things they didn’t dare before Actors embrace the reality of unplanned errors and adopt a pragmatic “Let It Crash” philosophy using supervision and self-healing to ensure impacted components are reset to a stable state and restarted upon failure ›› Case Study: Achieving consecutive quarters of member growth Today with its micro- services architecture, Weight Watchers has become a nimble development organization that innovates new customer services based on real-time data and integration with various devices, resulting in five consecutive quarters of recruitment growth READ MORE MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 14 Improving agility and time to value In a world where business models face constant disruption, your digital transformation initiative is likely driving you to embrace speed to remain competitive However, traditional application monoliths running on Java EE middleware were not designed with development agility in mind With no simple development model to support modern systems, the traditional compile-build-deploy cycle for every service cripples productivity ›› Work autonomously, deliver continuously The actor-based, asynchronous foundation of Light- bend Platforms supports the design of Reactive systems, which reduce dependencies between components and enable feature teams to work autonomously and deliver continuously, accelerating time to value by 2x to 3x ›› Case Study: Propagating changes 700% faster MoneySuperMarket Group (MSM), the holding company behind three of the UK’s most popular comparison shopping sites is propagating new features 700% faster, dramatically accelerating the time to revenue READ MORE Reducing compute costs while scaling elastically Nearly every digital transformation initiative includes a cloud strategy And, nearly every industry analyst will tell you, if you want to take advantage of the cloud, you can’t lift and shift Your applications need to be architected for the cloud In fact, Gartner is recommending you design every new application to be cloud-native, even if you plan to run it on-premise ›› Because our Platforms are actor-based and use asynchronous message passing, they more densely utilize commodity hardware compared with traditional systems bloated by locked threads Plus, the Platforms scale up and out effortlessly on multi-core and cloud computing architectures They handle bursty traffic with ease, without requiring hardware over provisioning, so you can reap the financial benefits of elasticity The added resilience, and cost savings, are huge ›› Case study: Saving 50% on infrastructure with no downtime After experiencing a horrific— and very public—downtime, Walmart Canada modernized its e-commerce platform, shaving 50% off infrastructure costs, and achieving unprecedented resilience READ MORE MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 15 Increasing developer happiness and productivity With your digital transformation, a tremendous amount of development lays ahead If your developers are hamstrung by old tools, it will be nearly impossible to keep your project on track and your top talent engaged ›› Making it easier, and faster, to build distributed systems Because the actor-model is at the heart of our application development platform, it alleviates the developer from having to deal with explicit locking and thread management, making it easier to write correct concurrent, parallel and distributed systems ›› Case Study: Boosting deployment frequency by 400% A modern Reactive development model that emphasizes proper service isolation has allowed developers at Norwegian Cruise Lines to continually roll out new features and bug fixes and deploy 400% more frequently READ MORE MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 16 The Days Of Java EE Heavyweight Middleware Are Ending “Our applications are able to serve over a billion hits a day with as little as VMs and vCPU each.” - PayPal After a decade or more of building Java EE monoliths that are slow to evolve, complicated to release, and expensive to maintain, modern enterprises are looking to new system architectures for running their business The Java EE heavyweight object-oriented method of software development is ill-suited to the always-on, real-time nature of cloud computing To achieve the full business benefits offered by the cloud, today’s systems must be lean, flexible, and Reactive Lightbend helps developers create applications that are responsive, resilient, flexible, and message-driven Built on a foundation of Domain Driven Design and based on actors rather than objects, Lightbend provides the perfect architecture for creating powerful, adaptable applications that thrive in the cloud MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 17 Your business needs to modernize Is the Lightbend application development platform the right solution? Let’s talk and find out CONTACT US Lightbend (Twitter: @Lightbend) provides the leading Reactive application development platform for building distributed applications and modernizing aging infrastructures Using microservices and fast data on a message-driven runtime, enterprise applications scale effortlessly on multi-core and cloud computing architectures Many of the most admired brands around the globe are transforming their businesses with our platform, engaging billions of users every day through software that is changing the world Lightbend, Inc 625 Market Street, 10th Floor, San Francisco, CA 94105 | www.lightbend.com ... Doctoral Dissertation MIT.) MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE 12 Modernizing with the Actor Model “For the first time in our history,... relevant when their initial version was put into production MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE Shifting Towards Actor- based Reactive... to real world domains The requirements of MSA can best be identified with the help of Domain Driven Design MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE