This document discusses designing microservices architectures. It begins by defining microservices as small, autonomous services that work together. The benefits of microservices include continuous innovation, independent deployments, and fault isolation. Challenges include complexity, testing, and service discovery. Key principles in designing microservices are modeling them around business domains, making each independently deployable, and decentralizing all components. Additional topics covered include service boundaries, communication patterns, data management, and monitoring microservices applications. The document provides examples and recommendations for implementing microservices on Azure.
Modern Cloud Fundamentals: Misconceptions and Industry TrendsChristopher Bennage
A discussion of misconceptions, problems, and industry trends that hinder adoption of cloud technology; with an emphasis on scenarios that appear to work but fail at critical moments.
Be sure to read the notes!
Modern Cloud Fundamentals: Misconceptions and Industry TrendsChristopher Bennage
A discussion of misconceptions, problems, and industry trends that hinder adoption of cloud technology; with an emphasis on scenarios that appear to work but fail at critical moments.
Be sure to read the notes!
The Future of Services: Building Asynchronous, Resilient and Elastic SystemsLightbend
In this talk by Jamie Allen, noted author, speaker and Senior Director of Global Solutions Architects at Lightbend, we will focus on how to build elastic, resilient service-based applications that can handle tremendous amounts of data in real time, and to introduce the new Lightbend framework for Microservices-based applications called "Lagom."
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!Continuent
With Multiple Active Primary MySQL Databases
Watch this on-demand webinar to learn the right way to deploy geo-distributed databases. We look at the pitfalls of deploying a single site and passive sites, and from there we show how to provide the best user experience by leveraging geo-distributed MySQL.
When considering geo-distributed MySQL database environments it is important to understand the nuances of having multiple active clusters deployed across sites and clouds. This webinar walks through the proper planning of geo-distributed MySQL for success.
Finally, you’ll learn about our best practices for multiple primary clusters, as well as failover and disaster recovery for MySQL.
AGENDA
- Why Geo-Distributed Databases
- Geo-Distributed MySQL Starts With High Performance Local Clusters
- Extend The Cluster To Multiple Datacenters/Clouds
- Best Practices For Multiple Primary Clusters
- Failover & Disaster Recovery
- Key Benefits
PRESENTER
Matthew Lang, Customer Success Director – Americas, Continuent, has over 25 years of experience in database administration, database programming, and system architecture, including the creation of a database replication product that is still in use today. He has designed highly available, scaleable systems that have allowed startups to quickly become enterprise organizations, utilizing a variety of technologies including open source projects, virtualization and cloud.
Microservices, Monoliths, SOA and How We Got HereLightbend
The Enterprise Architect’s Intro to Microservices - Part 1 of 3
**Find upcoming webinar details here: https://www.lightbend.com/community#filter:webinar**
If you’re tired of battling a monolithic enterprise system that’s difficult to scale and maintain––and even harder to understand––then this webinar series is for you. In these three expert sessions, we go over the details of why a microservice-based architecture that consists of small, independent services is far more flexible than the traditional all-in-one systems that continue to dominate today’s enterprise landscape.
In Part 1, Enterprise Advocate Kevin Webber will review a bit of history of application development, from the early days of monoliths and SOA to the emergence of Microservice architectures. We will review the drawbacks of heritage architectures and how the principles of Reactive can help you build isolated services that are scalable, resilient to failure, and combine with other services to form a cohesive whole.
In the next two webinars, we go deeper into the characteristics of Reactive Microservices, and the considerations how to build complete systems, presented by Lightbend CTO and Akka creator, Jonas Bonér.
The 6 Rules for Modernizing Your Legacy Java Monolith with MicroservicesLightbend
We change a monolithic system only when we have no other choice. Traditional enterprise systems are tightly-coupled; all-in-one, all-or-nothing, difficult to scale, difficult to understand and difficult to maintain.
Rather than swiftly capture opportunity, we ponder if it’s really worth it—is it worth upsetting the delicate balance of the house of cards we call our enterprise system? Often the opportunity quickly disappears, captured by a faster company. Some people have started calling this “Getting Ubered”.
So what can you do about it? Talking about Microservices is one thing, but how can your organization start taking action to address this issue?
In this webinar by battle-hardened Enterprise Advocate, Kevin Webber, we walk through the 6 key concepts to understand as a guide for taking action:
1. Domain Driven Design (DDD)
2. Asynchronous messaging
3. API management
4. Dependency management
5. CQRS & event sourcing
6. Transactions & ordering
Reactive Platform has what you need to breath new life into your legacy system with a new Microservices-based approach.
Nine Neins - where Java EE will never take youMarkus Eisele
Virtual JUG Session: http://www.meetup.com/virtualJUG/events/232052100/
With Microservices taking the software industry by storm, classical Enterprises are forced to re-think what they’ve been doing for almost a decade. It’s not the first time, that technology shocked the well-oiled machine to it’s core. We’ve seen software design paradigms changing over time and also project management methodologies evolving. Old hands might see this as another wave that will gently find it’s way to the shore of daily business. But this time it looks like the influence is bigger than anything we’ve seen before. And the interesting part is, that microservices aren’t new from the core. Talking about compartmentalization and introducing modules belongs to the core skills of architects. Our industry also learned about how to couple services and build them around organizational capabilities.
The really new part in microservices based architectures is the way how truly independent services are distributed and connected back together. Building an individual service is easy with all technologies. Building a system out of many is the real challenge because it introduces us to the problem space of distributed systems. And the difference to classical, centralized infrastructures couldn’t be bigger. There are very little concepts from the old world which still fit into a modern architecture.
And there are more differences between Java EE and distributed and reactive systems. For example, APIs are inherently synchronous, so most Java EE app servers have to scale by adding thread pools as so many things are blocking on I/O (remote JDBC calls, JTA calls, JNDI look ups, even JMS has a lot of synchronous parts). As we know adding thread pools doesn't get you too far in terms of scalability.
This talk is going to explore the nine most important differences between classical middleware and distributed, reactive microservices architectures and explains in which cases the distributed approach takes you, where Java EE never would.
FOR THE FULL VIDEO, RECORDING & PRESENTATION:
https://typesafe.com/blog/going-reactive-in-java-with-typesafe-reactive-platform
--
In this presentation by Jamie Allen, we do a deep dive into the Typesafe Reactive Platform from the Java developer’s perspective, to learn how Typesafe supports the entire Reactive application development lifecycle.
Reactive application development is becoming mainstream and considered a mission-critical need for future growth. This new wave of business applications are message-driven, elastic, resilient and responsive by nature, designed to scale elastically and maintain responsiveness during even large failures. With the Typesafe Reactive Platform (RP), including Play Framework and Akka, Java developers can start to use tools designed for building distributed systems that deliver highly-responsive user experiences. Regardless of whether you code in Java or Scala, Typesafe RP provides a resilient and message-driven application stack that scales effortlessly on multicore and cloud computing architectures.
In this webinar by Jonas Bonér, creator of Akka and CTO/Co-Founder of Lightbend, we take a look at Cloudstate, an OSS tool built on Akka, gRPC, Knative, GraalVM, and Kubernetes. Cloudstate lets you model, manage, and scale stateful services while preserving responsiveness by designing for resilience and elasticity.
Digital Transformation with Kubernetes, Containers, and MicroservicesLightbend
See the full presentation here: https://www.lightbend.com/blog/digital-transformation-kubernetes-containers-microservices
In this talk by David Ogren, Principal Enterprise Architect at Lightbend, we draw from experiences helping our clients successfully create, migrate to, and manage cloud-native system architectures.
Achieving scale and performance using cloud native environmentRakuten Group, Inc.
ID Platform Product can be used by every Rakuten Group Companies and can easily serve millions of users. Multi-Region product challenges are many, example:
- Ensure 4 9’s availability
- Management across each region
- Alerting and Monitoring across each region
- Auto scaling (Scale up and Scale down) across each region
- Performance (vertical scale up)
- Cost
- DB Consistency Across Multiple Regions
- Resiliency
At Ecosystem Platform Layer for Rakuten, we handle each of these and this presentation is about how we handle these challenging scenarios.
Overview of six architecture patterns: layered architecture, event-driven architecture (EDA), service-oriented architecture (SOA), pipeline architecture, microkernel architecture, space-based architecture. Explanation of their structure, pros and cons. Recommendation for further development.
How to Migrate to Cloud with Complete Confidence and TrustApcera
Henry Stapp, Director of Product Management at Apcera, explores the promises of the cloud and how new technologies (containers, micro-services, etc.) enable unparalleled speed and flexibility.
Caching for Microservices Architectures: Session IVMware Tanzu
In this 60 minute webinar, we will cover the key areas of consideration for data layer decisions in a microservices architecture, and how a caching layer, satisfies these requirements. You’ll walk away from this webinar with a better understanding of the following concepts:
- How microservices are easy to scale up and down, so both the service layer and the data layer need to support this elasticity.
- Why microservices simplify and accelerate the software delivery lifecycle by splitting up effort into smaller isolated pieces that autonomous teams can work on independently. Event-driven systems promote autonomy.
- Where microservices can be distributed across availability zones and data centers for addressing performance and availability requirements. Similarly, the data layer should support this distribution of workload.
- How microservices can be part of an evolution that includes your legacy applications. Similarly, the data layer must accommodate this graceful on-ramp to microservices.
Presenter : Jagdish Mirani is a Product Marketing Manager in charge of Pivotal’s in-memory products
Availability of Kafka - Beyond the Brokers | Andrew Borley and Emma Humber, IBMHostedbyConfluent
While Kafka has guarantees around the number of server failures a cluster can tolerate, to avoid service interruptions, or even data loss, it is prudent to have infrastructure in place for when an environment becomes unavailable during a planned or unplanned outage.
This talk describes the architectures available to you when planning for an outage. We will examine configurations including active/passive and active/active as well as availability zones and debate the benefits and limitations of each. We will also cover how to set up each configuration using the tools in Kafka.
Whether downtime while you fail over clients to a backup is acceptable or you require your Kafka clusters to be highly available, this talk will give you an understanding of the options available to mitigate the impact of the loss of an environment.
This session takes developers through a deep dive into microservices architecture on Amazon Web Services in the context of supporting transactions, making use of containerisation and serverless architectures and the various cloud-native features that make developing microservices efficient and simple.
Speaker: Oliver Klein – Emerging Technologies Solutions Architect, AWS APAC
The Future of Services: Building Asynchronous, Resilient and Elastic SystemsLightbend
In this talk by Jamie Allen, noted author, speaker and Senior Director of Global Solutions Architects at Lightbend, we will focus on how to build elastic, resilient service-based applications that can handle tremendous amounts of data in real time, and to introduce the new Lightbend framework for Microservices-based applications called "Lagom."
Webinar Slides: Geo-Distributed MySQL Clustering Done Right!Continuent
With Multiple Active Primary MySQL Databases
Watch this on-demand webinar to learn the right way to deploy geo-distributed databases. We look at the pitfalls of deploying a single site and passive sites, and from there we show how to provide the best user experience by leveraging geo-distributed MySQL.
When considering geo-distributed MySQL database environments it is important to understand the nuances of having multiple active clusters deployed across sites and clouds. This webinar walks through the proper planning of geo-distributed MySQL for success.
Finally, you’ll learn about our best practices for multiple primary clusters, as well as failover and disaster recovery for MySQL.
AGENDA
- Why Geo-Distributed Databases
- Geo-Distributed MySQL Starts With High Performance Local Clusters
- Extend The Cluster To Multiple Datacenters/Clouds
- Best Practices For Multiple Primary Clusters
- Failover & Disaster Recovery
- Key Benefits
PRESENTER
Matthew Lang, Customer Success Director – Americas, Continuent, has over 25 years of experience in database administration, database programming, and system architecture, including the creation of a database replication product that is still in use today. He has designed highly available, scaleable systems that have allowed startups to quickly become enterprise organizations, utilizing a variety of technologies including open source projects, virtualization and cloud.
Microservices, Monoliths, SOA and How We Got HereLightbend
The Enterprise Architect’s Intro to Microservices - Part 1 of 3
**Find upcoming webinar details here: https://www.lightbend.com/community#filter:webinar**
If you’re tired of battling a monolithic enterprise system that’s difficult to scale and maintain––and even harder to understand––then this webinar series is for you. In these three expert sessions, we go over the details of why a microservice-based architecture that consists of small, independent services is far more flexible than the traditional all-in-one systems that continue to dominate today’s enterprise landscape.
In Part 1, Enterprise Advocate Kevin Webber will review a bit of history of application development, from the early days of monoliths and SOA to the emergence of Microservice architectures. We will review the drawbacks of heritage architectures and how the principles of Reactive can help you build isolated services that are scalable, resilient to failure, and combine with other services to form a cohesive whole.
In the next two webinars, we go deeper into the characteristics of Reactive Microservices, and the considerations how to build complete systems, presented by Lightbend CTO and Akka creator, Jonas Bonér.
The 6 Rules for Modernizing Your Legacy Java Monolith with MicroservicesLightbend
We change a monolithic system only when we have no other choice. Traditional enterprise systems are tightly-coupled; all-in-one, all-or-nothing, difficult to scale, difficult to understand and difficult to maintain.
Rather than swiftly capture opportunity, we ponder if it’s really worth it—is it worth upsetting the delicate balance of the house of cards we call our enterprise system? Often the opportunity quickly disappears, captured by a faster company. Some people have started calling this “Getting Ubered”.
So what can you do about it? Talking about Microservices is one thing, but how can your organization start taking action to address this issue?
In this webinar by battle-hardened Enterprise Advocate, Kevin Webber, we walk through the 6 key concepts to understand as a guide for taking action:
1. Domain Driven Design (DDD)
2. Asynchronous messaging
3. API management
4. Dependency management
5. CQRS & event sourcing
6. Transactions & ordering
Reactive Platform has what you need to breath new life into your legacy system with a new Microservices-based approach.
Nine Neins - where Java EE will never take youMarkus Eisele
Virtual JUG Session: http://www.meetup.com/virtualJUG/events/232052100/
With Microservices taking the software industry by storm, classical Enterprises are forced to re-think what they’ve been doing for almost a decade. It’s not the first time, that technology shocked the well-oiled machine to it’s core. We’ve seen software design paradigms changing over time and also project management methodologies evolving. Old hands might see this as another wave that will gently find it’s way to the shore of daily business. But this time it looks like the influence is bigger than anything we’ve seen before. And the interesting part is, that microservices aren’t new from the core. Talking about compartmentalization and introducing modules belongs to the core skills of architects. Our industry also learned about how to couple services and build them around organizational capabilities.
The really new part in microservices based architectures is the way how truly independent services are distributed and connected back together. Building an individual service is easy with all technologies. Building a system out of many is the real challenge because it introduces us to the problem space of distributed systems. And the difference to classical, centralized infrastructures couldn’t be bigger. There are very little concepts from the old world which still fit into a modern architecture.
And there are more differences between Java EE and distributed and reactive systems. For example, APIs are inherently synchronous, so most Java EE app servers have to scale by adding thread pools as so many things are blocking on I/O (remote JDBC calls, JTA calls, JNDI look ups, even JMS has a lot of synchronous parts). As we know adding thread pools doesn't get you too far in terms of scalability.
This talk is going to explore the nine most important differences between classical middleware and distributed, reactive microservices architectures and explains in which cases the distributed approach takes you, where Java EE never would.
FOR THE FULL VIDEO, RECORDING & PRESENTATION:
https://typesafe.com/blog/going-reactive-in-java-with-typesafe-reactive-platform
--
In this presentation by Jamie Allen, we do a deep dive into the Typesafe Reactive Platform from the Java developer’s perspective, to learn how Typesafe supports the entire Reactive application development lifecycle.
Reactive application development is becoming mainstream and considered a mission-critical need for future growth. This new wave of business applications are message-driven, elastic, resilient and responsive by nature, designed to scale elastically and maintain responsiveness during even large failures. With the Typesafe Reactive Platform (RP), including Play Framework and Akka, Java developers can start to use tools designed for building distributed systems that deliver highly-responsive user experiences. Regardless of whether you code in Java or Scala, Typesafe RP provides a resilient and message-driven application stack that scales effortlessly on multicore and cloud computing architectures.
In this webinar by Jonas Bonér, creator of Akka and CTO/Co-Founder of Lightbend, we take a look at Cloudstate, an OSS tool built on Akka, gRPC, Knative, GraalVM, and Kubernetes. Cloudstate lets you model, manage, and scale stateful services while preserving responsiveness by designing for resilience and elasticity.
Digital Transformation with Kubernetes, Containers, and MicroservicesLightbend
See the full presentation here: https://www.lightbend.com/blog/digital-transformation-kubernetes-containers-microservices
In this talk by David Ogren, Principal Enterprise Architect at Lightbend, we draw from experiences helping our clients successfully create, migrate to, and manage cloud-native system architectures.
Achieving scale and performance using cloud native environmentRakuten Group, Inc.
ID Platform Product can be used by every Rakuten Group Companies and can easily serve millions of users. Multi-Region product challenges are many, example:
- Ensure 4 9’s availability
- Management across each region
- Alerting and Monitoring across each region
- Auto scaling (Scale up and Scale down) across each region
- Performance (vertical scale up)
- Cost
- DB Consistency Across Multiple Regions
- Resiliency
At Ecosystem Platform Layer for Rakuten, we handle each of these and this presentation is about how we handle these challenging scenarios.
Overview of six architecture patterns: layered architecture, event-driven architecture (EDA), service-oriented architecture (SOA), pipeline architecture, microkernel architecture, space-based architecture. Explanation of their structure, pros and cons. Recommendation for further development.
How to Migrate to Cloud with Complete Confidence and TrustApcera
Henry Stapp, Director of Product Management at Apcera, explores the promises of the cloud and how new technologies (containers, micro-services, etc.) enable unparalleled speed and flexibility.
Caching for Microservices Architectures: Session IVMware Tanzu
In this 60 minute webinar, we will cover the key areas of consideration for data layer decisions in a microservices architecture, and how a caching layer, satisfies these requirements. You’ll walk away from this webinar with a better understanding of the following concepts:
- How microservices are easy to scale up and down, so both the service layer and the data layer need to support this elasticity.
- Why microservices simplify and accelerate the software delivery lifecycle by splitting up effort into smaller isolated pieces that autonomous teams can work on independently. Event-driven systems promote autonomy.
- Where microservices can be distributed across availability zones and data centers for addressing performance and availability requirements. Similarly, the data layer should support this distribution of workload.
- How microservices can be part of an evolution that includes your legacy applications. Similarly, the data layer must accommodate this graceful on-ramp to microservices.
Presenter : Jagdish Mirani is a Product Marketing Manager in charge of Pivotal’s in-memory products
Availability of Kafka - Beyond the Brokers | Andrew Borley and Emma Humber, IBMHostedbyConfluent
While Kafka has guarantees around the number of server failures a cluster can tolerate, to avoid service interruptions, or even data loss, it is prudent to have infrastructure in place for when an environment becomes unavailable during a planned or unplanned outage.
This talk describes the architectures available to you when planning for an outage. We will examine configurations including active/passive and active/active as well as availability zones and debate the benefits and limitations of each. We will also cover how to set up each configuration using the tools in Kafka.
Whether downtime while you fail over clients to a backup is acceptable or you require your Kafka clusters to be highly available, this talk will give you an understanding of the options available to mitigate the impact of the loss of an environment.
This session takes developers through a deep dive into microservices architecture on Amazon Web Services in the context of supporting transactions, making use of containerisation and serverless architectures and the various cloud-native features that make developing microservices efficient and simple.
Speaker: Oliver Klein – Emerging Technologies Solutions Architect, AWS APAC
Why do we build applications based on microservices? To gain flexibility and resilience - that’s what everybody tells us. But building and application with a lot of microservices leads to a highly distributed system - and distribution hurts! How can we keep dependencies between microservices at the lowest possible level and how can we reduce communication between them? We will have a look at „Event-Sourcing“ as a possible (and very cool) technique for asynchronous communication and data exchange/replication between microservices - in theory and also in code.
Presented at CodeFest 2014
Whether you are logging for the purpose of diagnostics or monitoring, it requires proper, well-designed instrumentation and a sound strategy. The new Semantic Logging Application Block (SLAB) offers a smarter way of logging by keeping the structure of the events when writing log messages to multiple destinations such as rolling flat file, database or Windows Azure table storage. In this talk, we will give an introduction to SLAB and provide a time of Q&A. We will address questions like:
* What are the pros and cons of using SLAB?
* What is the performance impact?
* How can I extend SLAB?
* Do I have to commit to using ETW?
* Does SLAB support .NET’s EventSoure?
* How extensible is SLAB? Can you provide an example?
* Can you use SLAB without knowledge of ETW?
* What is the trade-off between using SLAB in-process vs out-of-process?
* How steep is the learning curve? How do I get started?
* How can I contribute to SLAB?
A discussion of some typical misconceptions related to the performance of high scale distributed systems, examples of some common anti-patterns, and a brief outline for analyzing performance.
SIGNificant ColorPad 6 – The perfect signature pad.
End-to-end security – Encryption of the sensitive signature row data takes place on the pad, rather than in the unsafe “computer” environment.
Display the whole document – The signature pad can show the whole document (multilateral), not just parts of it limited to the screen size of the pad. Buttons on the pad allow for document browsing via vertical or horizontal scrolling and zooming.
Patented palm rest – The unique palm rest allows for natural signing like on paper and thus recording a natural signature – unlike other pads, where your hand is quickly hovering up in the air.
Sign directly onto documents – it’s almost like signing a paper document.
No driver installation necessary – Thanks to the “Encrypted HID Standard”, driver installation is not required for W2000, XP, Vista, Win7, Linux and MAC OSX.
Mode for left hand writing – Both left-handed and right-handed people can find the optimum position for writing. The screen can be rotated through 180⁰.
Advertising – The brilliant color display, with a resolution of 640×480 pixels, can present your latest offers, products, solutions and services perfectly in standby mode. Moreover, the whole pad can be customized according to your CI. See example on the left.
Pen holder – The pad includes a holder in the side for secure storage of the pen during transport, as well as a second, vertical holder for when the pad is in use. The pen is attached by a cord to ensure its safekeeping.
Mounting possibilities – On the back of the signature device are two screw holes for table and wall mounting. Accessories for mounting are sold separately.
Key findings:
52% of respondents use mobile Internet several times per day or “almost all the time”, 27% once or twice per day
29% started using mobile Internet less than 1 year ago
Mobile Internet is used mostly for information (50%) and communication (45%) purposes. 66% of respondents visit mobile or non mobile sites, 37% check emails, 33% use instant messaging, 33% use other mobile apps, 25% download music, games or videos.
Methodology:
This mobile web survey was initiated with SMS invitations. SMS invitations were sent to subscribers immediately after they topped up their mobile account via QIWI offline payment terminals.
With a response rate reaching 0.84%, 312 forms were submitted from 14 to 16 April 2011 in Moscow. As a reward, 10 rub. ($0.35) were added to the participants’ account.
Платформа SIGNificant от xyzmo сожержит весь необходимый пользовательский интерфейс и инструменты для вашей успешной реализации и оформления электронной подписи (ЭЦП) и пользовательского опыта. Будь то планшет для цифровых подписей, интерактивный перьевой дисплей, мобильное устройство или электронное веб пространство, блоки составляющие платформу упрощают сбор и подбор наилучшей комбинации решений для электронной подписи и устройств для ЭЦП в соответствии с каждым пользовательским случаем.
In this presentation, Siddarth explains the topic of IoT and associated trends. He is interested in developing network modules and programming devices for machine to machine communication.
Real-Time Communications between MicroservicesSolace
This presentation is from the Pivotal Cloud Foundry meetup in Columbus, Ohio, on February 23, 2017.
------------
Learn the advantages of enabling communications between applications using open APIs and protocols like AMQP, JMS, MQTT, Qpid, Paho, REST and WebSockets. Mark Spielman demonstrates how easily you can enable real-time communications between microservices with the new Solace Messaging Tile for Pivotal Cloud Foundry. We’ll then discuss the architecture and code that makes it all possible.
Join us to learn how you can improve the way your applications exchange information both within Pivotal Cloud Foundry and across clouds.
Cloud-native Data: Every Microservice Needs a Cachecornelia davis
Presented at the Pivotal Toronto Users Group, March 2017
Cloud-native applications form the foundation for modern, cloud-scale digital solutions, and the patterns and practices for cloud-native at the app tier are becoming widely understood – statelessness, service discovery, circuit breakers and more. But little has changed in the data tier. Our modern apps are often connected to monolithic shared databases that have monolithic practices wrapped around them. As a result, the autonomy promised by moving to a microservices application architecture is compromised.
With lessons from the application tier to guide us, the industry is now figuring out what the cloud-native architectural patterns are at the data tier. Join us to explore some of these with Cornelia Davis, a five year Cloud Foundry veteran who is now focused on cloud-native data. As it happens, every microservice needs a cache and this evening will drill deep on that topic. She’ll cover a variety of caching patterns and use cases, and demonstrate how their use helps preserve the autonomy that is driving agile software delivery practices today.
Stay productive while slicing up the monolithMarkus Eisele
Microservices-based architectures are in vogue. Over the last couple of years, we have learned how thought leaders implement them, and it seems like every other week we hear about how containers and platform-as-a-service offerings make them ultimately happen.
Tech Talent Night Copenhagen 11/22/17
https://greenticket.dk/techtalentnightcph
Service Fabric – building tomorrows applications todayBizTalk360
This session walks through incorporating Microsoft Service Fabric into your next application for zero downtime and upgradability. Microsoft have released the very same Azure Fabric smarts that look after for e.g. Azure VM management, into the Application space. Meaning your Apps can be based on the Actor model, highly distributed, scalable and in place upgrades with zero down time is now possible. Tapping into scale is key in this world of Cloud First, Device First world - can your apps handle the load? Bring the management of Azure to your application layer.
Are you jumping on the microservices bandwagon? When and when not to adopt micro services architecture? If you must, what are the considerations? This slidedeck will help answer a few of those questions...
Microservices is a software architecture design pattern in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.
(ARC309) Getting to Microservices: Cloud Architecture PatternsAmazon Web Services
Gilt, a billion dollar e-commerce company, implemented a sophisticated microservices architecture on AWS to handle millions of customers visiting their site at noon every day. The microservices architecture pattern enables independent service scaling, faster deployments, better fault isolation, and graceful degradation. In this session, Derek Chiles, AWS solutions architect, will review best practices and recommended architectures for deploying microservices on AWS. Adrian Trenaman, SVP of engineering at Gilt, will share Gilt's experiences and lessons learned during their evolution from a single monolithic Rails application in a traditional data center to more than 300 Scala/Java microservices deployed in the cloud.
Following simple patterns of good application design can allow you to scale your application for your customers easily. This presentation dives into the 12 factor application design and demo how this applies to containers and deployments on Amazon ECS and Fargate. We'll take a look at tooling that can be used to simplify your workflow and help you adopt the principles of the 12 factor application.
The introduction covers the following
1. What are Microservices and why should be use this paradigm?
2. 12 factor apps and how Microservices make it easier to create them
3. Characteristics of Microservices
Note: Please download the slides to view animations.
Concurrency at Scale: Evolution to Micro-ServicesRandy Shoup
Most large-scale web companies have evolved their system architecture from a monolithic application and monolithic database to a set of loosely coupled micro-services. Using examples from Google, eBay, and KIXEYE, this talk outlines the pros and cons of these different stages of evolution, and makes practical suggestions about when and how other organizations should consider migrating to micro-services. It concludes with some more advanced implications of a micro-services architecture, including SLAs, cost-allocation, and vendor-customer relationships within the organization.
The Microservices approach is a new way of building composable, cloud-native applications. This session is designed for developers who are transforming existing applications to Microservices, or creating new Microservices style applications. The session will cover best practices, patterns including Service Registration and Discovery, and key development tools required for building distributed Microservices style applications. The session will also cover best practices for automating the operations of these applications, using container orchestration services.
Amazon EKS 그리고 Service Mesh
Kubernetes는 컨테이너 서비스를 도입하는 기업들에게 가장 있기있는 Orchestration 플랫폼입니다. 이 세션에서는 아마존에서 6월 정식 출시한 managed Kubenetes서비스인 EKS를 소개해드리며, 오픈소스 버전과의 차이점 및 장점 등에 대해 설명하고, 진보한 마이크로 서비스인 Service Mesh를 구현하는 Linkerd 소개 및 데모를 진행하고자 합니다.
Application Centric Microservices from Redhat Summit 2015Ken Owens
When Cisco started envisioning the future of its application development platforms, the ability to create applications that are cloud-native with elastic services, network-aware application policies, and micro-services was strategic to the company. When the decision to build and operate a Cisco cloud service delivery platform for collaboration, video, and Internet of Things (IoT) application development was made, OpenStack and micro-services became central to our application architectures and strategic to our vision as a company. This presentation will look at the journey Cisco developers took to transform to an application-centric OpenStack platform for application development in a secure, network-centric, and completely open source manner. The importance of the platform being Red Hat Enterprise Linux OpenStack Platform and using OpenShift by Red Hat and the contribution to the community will be described. The micro-services architecture and service-oriented DevOps lessons learned for enabling massive scalable and continuous delivery of software will be presented and demoed.
Forklift Classes Overview by Intella PartsIntella Parts
Discover the different forklift classes and their specific applications. Learn how to choose the right forklift for your needs to ensure safety, efficiency, and compliance in your operations.
For more technical information, visit our website https://intellaparts.com
Saudi Arabia stands as a titan in the global energy landscape, renowned for its abundant oil and gas resources. It's the largest exporter of petroleum and holds some of the world's most significant reserves. Let's delve into the top 10 oil and gas projects shaping Saudi Arabia's energy future in 2024.
NO1 Uk best vashikaran specialist in delhi vashikaran baba near me online vas...Amil Baba Dawood bangali
Contact with Dawood Bhai Just call on +92322-6382012 and we'll help you. We'll solve all your problems within 12 to 24 hours and with 101% guarantee and with astrology systematic. If you want to take any personal or professional advice then also you can call us on +92322-6382012 , ONLINE LOVE PROBLEM & Other all types of Daily Life Problem's.Then CALL or WHATSAPP us on +92322-6382012 and Get all these problems solutions here by Amil Baba DAWOOD BANGALI
#vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore#blackmagicformarriage #aamilbaba #kalajadu #kalailam #taweez #wazifaexpert #jadumantar #vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore #blackmagicforlove #blackmagicformarriage #aamilbaba #kalajadu #kalailam #taweez #wazifaexpert #jadumantar #vashikaranspecialist #astrologer #palmistry #amliyaat #taweez #manpasandshadi #horoscope #spiritual #lovelife #lovespell #marriagespell#aamilbabainpakistan #amilbabainkarachi #powerfullblackmagicspell #kalajadumantarspecialist #realamilbaba #AmilbabainPakistan #astrologerincanada #astrologerindubai #lovespellsmaster #kalajaduspecialist #lovespellsthatwork #aamilbabainlahore #Amilbabainuk #amilbabainspain #amilbabaindubai #Amilbabainnorway #amilbabainkrachi #amilbabainlahore #amilbabaingujranwalan #amilbabainislamabad
Courier management system project report.pdfKamal Acharya
It is now-a-days very important for the people to send or receive articles like imported furniture, electronic items, gifts, business goods and the like. People depend vastly on different transport systems which mostly use the manual way of receiving and delivering the articles. There is no way to track the articles till they are received and there is no way to let the customer know what happened in transit, once he booked some articles. In such a situation, we need a system which completely computerizes the cargo activities including time to time tracking of the articles sent. This need is fulfilled by Courier Management System software which is online software for the cargo management people that enables them to receive the goods from a source and send them to a required destination and track their status from time to time.
COLLEGE BUS MANAGEMENT SYSTEM PROJECT REPORT.pdfKamal Acharya
The College Bus Management system is completely developed by Visual Basic .NET Version. The application is connect with most secured database language MS SQL Server. The application is develop by using best combination of front-end and back-end languages. The application is totally design like flat user interface. This flat user interface is more attractive user interface in 2017. The application is gives more important to the system functionality. The application is to manage the student’s details, driver’s details, bus details, bus route details, bus fees details and more. The application has only one unit for admin. The admin can manage the entire application. The admin can login into the application by using username and password of the admin. The application is develop for big and small colleges. It is more user friendly for non-computer person. Even they can easily learn how to manage the application within hours. The application is more secure by the admin. The system will give an effective output for the VB.Net and SQL Server given as input to the system. The compiled java program given as input to the system, after scanning the program will generate different reports. The application generates the report for users. The admin can view and download the report of the data. The application deliver the excel format reports. Because, excel formatted reports is very easy to understand the income and expense of the college bus. This application is mainly develop for windows operating system users. In 2017, 73% of people enterprises are using windows operating system. So the application will easily install for all the windows operating system users. The application-developed size is very low. The application consumes very low space in disk. Therefore, the user can allocate very minimum local disk space for this application.
Immunizing Image Classifiers Against Localized Adversary Attacksgerogepatton
This paper addresses the vulnerability of deep learning models, particularly convolutional neural networks
(CNN)s, to adversarial attacks and presents a proactive training technique designed to counter them. We
introduce a novel volumization algorithm, which transforms 2D images into 3D volumetric representations.
When combined with 3D convolution and deep curriculum learning optimization (CLO), itsignificantly improves
the immunity of models against localized universal attacks by up to 40%. We evaluate our proposed approach
using contemporary CNN architectures and the modified Canadian Institute for Advanced Research (CIFAR-10
and CIFAR-100) and ImageNet Large Scale Visual Recognition Challenge (ILSVRC12) datasets, showcasing
accuracy improvements over previous techniques. The results indicate that the combination of the volumetric
input and curriculum learning holds significant promise for mitigating adversarial attacks without necessitating
adversary training.
Democratizing Fuzzing at Scale by Abhishek Aryaabh.arya
Presented at NUS: Fuzzing and Software Security Summer School 2024
This keynote talks about the democratization of fuzzing at scale, highlighting the collaboration between open source communities, academia, and industry to advance the field of fuzzing. It delves into the history of fuzzing, the development of scalable fuzzing platforms, and the empowerment of community-driven research. The talk will further discuss recent advancements leveraging AI/ML and offer insights into the future evolution of the fuzzing landscape.
Sachpazis:Terzaghi Bearing Capacity Estimation in simple terms with Calculati...Dr.Costas Sachpazis
Terzaghi's soil bearing capacity theory, developed by Karl Terzaghi, is a fundamental principle in geotechnical engineering used to determine the bearing capacity of shallow foundations. This theory provides a method to calculate the ultimate bearing capacity of soil, which is the maximum load per unit area that the soil can support without undergoing shear failure. The Calculation HTML Code included.
About
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
Technical Specifications
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
Key Features
Indigenized remote control interface card suitable for MAFI system CCR equipment. Compatible for IDM8000 CCR. Backplane mounted serial and TCP/Ethernet communication module for CCR remote access. IDM 8000 CCR remote control on serial and TCP protocol.
• Remote control: Parallel or serial interface
• Compatible with MAFI CCR system
• Copatiable with IDM8000 CCR
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
Application
• Remote control: Parallel or serial interface.
• Compatible with MAFI CCR system.
• Compatible with IDM8000 CCR.
• Compatible with Backplane mount serial communication.
• Compatible with commercial and Defence aviation CCR system.
• Remote control system for accessing CCR and allied system over serial or TCP.
• Indigenized local Support/presence in India.
• Easy in configuration using DIP switches.
Explore the innovative world of trenchless pipe repair with our comprehensive guide, "The Benefits and Techniques of Trenchless Pipe Repair." This document delves into the modern methods of repairing underground pipes without the need for extensive excavation, highlighting the numerous advantages and the latest techniques used in the industry.
Learn about the cost savings, reduced environmental impact, and minimal disruption associated with trenchless technology. Discover detailed explanations of popular techniques such as pipe bursting, cured-in-place pipe (CIPP) lining, and directional drilling. Understand how these methods can be applied to various types of infrastructure, from residential plumbing to large-scale municipal systems.
Ideal for homeowners, contractors, engineers, and anyone interested in modern plumbing solutions, this guide provides valuable insights into why trenchless pipe repair is becoming the preferred choice for pipe rehabilitation. Stay informed about the latest advancements and best practices in the field.
Event Management System Vb Net Project Report.pdfKamal Acharya
In present era, the scopes of information technology growing with a very fast .We do not see any are untouched from this industry. The scope of information technology has become wider includes: Business and industry. Household Business, Communication, Education, Entertainment, Science, Medicine, Engineering, Distance Learning, Weather Forecasting. Carrier Searching and so on.
My project named “Event Management System” is software that store and maintained all events coordinated in college. It also helpful to print related reports. My project will help to record the events coordinated by faculties with their Name, Event subject, date & details in an efficient & effective ways.
In my system we have to make a system by which a user can record all events coordinated by a particular faculty. In our proposed system some more featured are added which differs it from the existing system such as security.
Final project report on grocery store management system..pdfKamal Acharya
In today’s fast-changing business environment, it’s extremely important to be able to respond to client needs in the most effective and timely manner. If your customers wish to see your business online and have instant access to your products or services.
Online Grocery Store is an e-commerce website, which retails various grocery products. This project allows viewing various products available enables registered users to purchase desired products instantly using Paytm, UPI payment processor (Instant Pay) and also can place order by using Cash on Delivery (Pay Later) option. This project provides an easy access to Administrators and Managers to view orders placed using Pay Later and Instant Pay options.
In order to develop an e-commerce website, a number of Technologies must be studied and understood. These include multi-tiered architecture, server and client-side scripting techniques, implementation technologies, programming language (such as PHP, HTML, CSS, JavaScript) and MySQL relational databases. This is a project with the objective to develop a basic website where a consumer is provided with a shopping cart website and also to know about the technologies used to develop such a website.
This document will discuss each of the underlying technologies to create and implement an e- commerce website.
2. Agenda
• What is microservices?
• Benefits / Challenges
• Designing microservices
• Migrating to microservices
3. What is microservices?
Small autonomous services that work together,
modeled around a business domain
- Sam Newman -
Loosely coupled service oriented architecture
with bounded contexts
- Adrian Cockcroft-
5. Why microservices? Why not monolith?
Release
Dev team A
Dev team B
Dev team C
Dev team D
Dev team E
Production
.
.
.
Common dependency
- Data schema
- Message schema
- Leaking service internals via API
- Framework/Library version
- Shared component
6. Why microservices? Why not monolith?
Dev team A
Dev team B
Dev team C
Dev team D
Dev team E
Production
.
.
.
Release
Production
Production
Production
Production
Release
Release
Release
Release
How many changes each release should include?Integration, E2E test?
7. DevOps practices
Source: 2016 DevOps pulse
How frequently do you deploy code?
Do you have continuous integration in place?
Do you have continuous deployment in place?
9. microservices - Benefits
• Continuous innovation
• Independent deployments
• Technology diversity
• Small focused team
• Separate scalability/availability
• Fault isolation
10. microservices - Challenges
• Complexity
• Network congestion
• Data integrity/consistency
• Integration and versioning
• Testing
• Reliability
• Service discovery and routing
• Monitoring and logging
11. microservices - Principles
• Model services around a business domain
• Make each service independently deployable
• Decentralize all things
• Hide implementation details
• Data is private to its service
• Automate DevOps tasks
• Isolate failure
12. Designing microservices
• Service boundary
• Granularity
• Gateway
• Offloading, Aggregation, Routing
• Inter service communication
• Sync/Async, Protocol/Serialization, Messaging
• Data management
• Integrity/Consistency
• Distributed transactions
• Dealing with partial failure
• Monitoring
• Sidecar, Distributed tracing
13. Finding service boundary
• Start with bounded context
• Further breakdown per non-functional requirements
• Vertical decomposition rather than horizontal (layers)
• Also consider
• Rate of change
• Technology used
• Communication overhead
• Splitting data is challenge due to consistency issues
• Refactoring across boundary is an extremely expensive operation
15. Inter service communication
Svc
A
Svc
B
Svc
D
Svc
E
GW
North – South request
East–West
Challenges
- Endpoint proliferation
- East – West chattiness
- Overhead by serialization
- Different svc lifecycle requires decoupling
- Versioning
- IP masquerading
16. Data integrity/consistency
Survey Tenant
Survey ID Tenant ID Questions Tenant ID Tenant Name Survey count
1234 001 001 Fabrikam 99Do you know Surface?
Replica of
Tenant DB
Survey
Event
Atomic?
N < 100 ?
Yes
Message Broker
100
Single
Transaction
scope
17. Decoupling data by CQRS
Survey
Survey
Analysis
Survey ID Tenant ID Answers
1234 001 2.0, 3.5, 4.0, …
Survey ID Tenant Name Answers
1234 Fabrikam 992.0, 3.5, 4.0, …
MessageBroker
Write model Read model
Eventually consistent
18. Reversible workflow by Sagas
• Sagas is long running transactions that can be written as a sequence
of transactions that can be interleaved with other transactions.
- Hector Garcia Molina , et al. 1987-
Svc
A
Svc
B
Svc
C
Order
Mgmt
Place an order
Decrease stock level
Delegate shipping
Cancel
Retry
Managing State
Retry
Timeout
Concurrency
scheduler agent supervisor pattern
19. Monitoring microservices
Svc
A
Svc
B
Svc
D
GW
- Correlating distributed transactions
- Sidecar pattern for cross language env
- APM tools
- Logging at GW
- Monitor system as a whole
Side
car
Side
car
Side
car
Activity #1
Activity #1
Activity #1
20. Options to implement microservices on Azure
• Service Fabric
• Azure Container Service
• Azure functions
• Docker cloud (supports Azure)
• Docker on Virtual Machine
• App service
21. Container and orchestration
DevOps
User
Application
Gateway
Application Host
Master
Image
Registry
Nginx /HA proxy
App GW
Docker Hub
ACR
Docker engine on
Virtual Machines
Kubernetes
Marathon
Swarm
Request
Repository
Validation
Cluster state
store
Etcd
Consul
Zookeeper
Administor
Docker
imageDocker
image
Node state tracking
Discovery
Leader election
Deployment
Cluster management
Routing
Load balancing
Offloading
Run services
23. Migrating monolith to microservices
• Extract one service at a time
• Add glue code that takes care of dirty work
• Strangler / Anti-corruption layer in transition period
Monolith
(Big ball of mud)
microservicesCoarse grained
Somewhat decomposed
26. Summary
• microservices is not something running on containers
• Choose microservices for continuous innovation
• Independent deployment is the key
• Incrementally migrate from monolith to MSA
• Use a few hosting options on Azure
27. Resources
• Microservices with Docker on Microsoft Azure (Trent Swanson, et al.)
• Building microservices (Sam Newman)
• Microservice architecture (Irakli Nadareishvili, et al.)
• https://www.nginx.com/blog/introduction-to-microservices/
• http://www.vinaysahni.com/best-practices-for-building-a-microservice-
architecture
• http://www.grahamlea.com/2015/07/microservices-security-questions/
• Principles of Microservices by Sam Newman
• Adrian Cockcroft on InfoQ
• Service fabric training course on MVA
Editor's Notes
Why do we need to consider moving to MS or we don’t need to?
You don’t necessarily always move to MS. What kind of benefit you get, does it justify paying lots of effort?
In order to take advantage of benefits and address challenges, you need to design it correctly.
What are options to implement MS on Azure.
This is a quote from Sam Newman
Another quote from Adrian Cockcroft
Traditional 3 tier or N tier architecture with horizontal layering.
Most of the great MSA examples uses to be in this design, Netflix, LinkedIn, Uber etc.
MSA is a Vertical (functional) slice of monolith. Each and every function becomes separate MS
One service represents one responsibility
Instead of having a single DB, most likely Each service may choose the right storage types from RDB or NoSQL.
. Polyglot persistence approach
As part of refactoring, MS will expose API , UI layer become SPA or mobile that consume that API
Why do we need to move to MSA? There’re reasons users are moving to MSA. This is #1 reason among them.
This is what we do with monolith. Unified single code base with a single release pipeline.
A bug found in one team will block the whole release process
If the size of the developer goes big, then it’s not manageable.
Testing, fixing, breaking dependentants are the blocker
Feature C depends on A in terms of.
- Data schema
Leaking service internals via API
Library version
- Service bus / API gateway (Fat gateway)
With MSA, each team owns its service and deploy them separately into separate production environment most likely containers which is isolated from each other.
So even if one of the services has a problem, it wouldn’t affect other services.
Obvious question is How much changes each release should include?
Netflix allows to deploy only one significant change at a time.
Another question, How can we do integration testing or E2E testing?
- Test against contract using stub, tools like Pact (test both consumer/provider against contract)
Canary release
Test in production
Roll back deployment
Now we understand that the benefit of MSA is faster release but do we care such a faster frequent release cycle?
Let’s see how often users are deploying new code.
According to DevOps pulse, 20% of respondents deploy new code multiple times a day, 60% do more than a few times a week.
CI/CD adoption is also very high.
More than 70% of users already have them in place or working on it.
Almost same number to continuous deployment.
Quite a lot of users already adopted these DevOps practice and the adoption rate is increasing.
Let’s take a look at a few case studies.
Netflix started refactoring their system in 2008. Back then their business was sending DVD. Now it changed primarily to live streaming where user retention matters. Longer a user stays the better. In fact 0.1% gain in retention means a lot to their business. So they always do A/B testing in terms of UI, algorithm etc. Then deploy new feature very quick. They call this feature velocity which now became one of their core competence.
They started moving monolith in on-prem to MSA in the cloud which took 7 years to complete. Now they’re running 400+ microservices. They OSSed their components as Hystrix.
Pokemon GO had 50x more traffic than they expected on the day they launched it. Their app is running on Kubenetes on Google container engine. Because of the influx of requests, the LB became a bottleneck. They needed to optimize LB to meet the demands. It is the largest Kubernetes deployment on GCE.
Spotify serves 75 mil users in 58 countries. They say their business rules are incredibly complex.
They had very common challenges such as UX depends on shared library which depends on server and infrastructure so that was super hard to change something without breaking other part of the system. In order to solve this issue they split 600+ devs into 90+ teams. Each team own its autonomous service. Now they have 800+ services. They OSSed components as Apollo.
LinkedIn also started as monolith (Java, servlet, Oracle), then went to CQRS architecture to support member-connection graph.
Then they went into 300+ fine-grained services with monolithic build and release process meaning they didn’t exploit microservices benefit yet. Eventually they optimized build and release process to take full advantage of MSA.
One interesting fact is that they brought the nortion of tiers into MSA as a way to manage dependency. Services in front tier only talk to middle tier, middle tier only talk to backend tier. The services in backend tier talk each other but never go outside its boundary. It’s tier within the bounded context.
They depend Deco for cross domain data reference and REST.LI for inter service communication.
Well, you may think that I’m not developing Netflix, nor Pokemon Go..
However MSA gives you benefits regardless of the size of company or service.
Most of the benefits are from DevOps point of view.
Biggest benefit among all is that it enables continuous innovation. Like we see in Netflix.
To support continuous innovation, it needs to be deployed independently without worrying about other services
MSA enables it by isolating each service.
By isolating microservices, you can choose right technology for right purpose such as library, language etc. You’re free from version hell too.
Decomposition of monolith enables them to scale differently.
Ramping up time will be short because of the size of service
Fault isolation can’t come with free. You need to explicitly isolate faults by bulkhead, circuit breaker etc.
You won’t get these benefits for free. You have to design MSA in a way to gain them.
We’ll discuss it a few slides later
New arch style always come with new set of challenges. In the case of microservices, This is it.
Each service gets simpler with a clear focus and boundary
In exchange, now the complexity shifts to orchestration part
Since each service owns it’s private data they need to communicate via API. When you have 100s of services talking to each other, you now notice that how much congestion you’ll see.
For the same reason, you’ll see lots of data integrity/consistency issues because of data fragmentation.
Since each service can be developed and deployed independently, integrating them and versioning them
Testing MSA is one of the biggest challenges because of service dependencies. Integration/E2E testing will be challenge. Rate of change is different, luck of tools. Stubs and mocks are required. Importance of automation.
More service means more surface area to break. In dependent deployment doesn’t mean there’s no runtime dependency
In MSA, service location is dynamic, based on cluster state, resource usage. Relocation is common. You need to route request to the right instance.
Monitoring hundreds of services that are potentially using different technologies, languages is a big challenge. We’ll discuss this later in the session.
Density in the cluster make it difficult
http://mantl.io/technologies
Don’t do layering across business domains which causes dependency
No shared Library, configuration, framework. Everything needs to be self-contained so it can be deployed independently
Decentralize repository, build process, LB, data and governance
Don’t leak implementation details to other services which causes dependency
Data must be private to its service meaning anybody else can’t directly access other’s data
N times of deployment for N services. Automation is the key to solve that issue.
All techniques that we discussed in resiliency session can apply here. Circuit breaker, bulkhead, retry, timeout etc.
We’re expanding the notion of high cohesion loosely coupling to DevOps area such as build, test, deploy for faster evolution
How can we design these principles in your system? Let’s take a look.
Now we understand the principles, how can we bring them to life?
Translate the principles into actionable design items.
If you scan through existing articles, videos, and training materials, these are the topics that they’re talking about.
How do we know about the right granularity? Smaller is better as in lean startup, agile manifesto, CI/CD practice?
Smaller means more services means more orchestration among services and data they own.
GW plays three key roles. We’ll discuss them later.
With 100s of services, inter SVC comm has lots of challenges, perf overhead, decoupling
How can you maintain data integrity, consistency across partitions?
Since we have small granular services, A transaction is most likely span across multiple services. How can we deal with partial failure.
Monitoring one service may easy but monitoring system as a whole is difficult.
Async IO w/ REST or Async messaging
Consul supports HEM pattern
Understanding the domain is super important
BC is the boundary of the system where same model / language applies. It could be team organization, data type, infrastructure etc. It is a way for separation of concerns.
Workload with diff Scalability, availability, security can be split into diff services
It’s not always smaller is better.
Other boundaries.
Deployment, Dev/Test, Communication, Technology, Resource allocation, scale, SLA, security, data to fetch, discovery, team, monitoring, versioning etc.
Routing based on IP+port#. It also has to consider node state.
If majority of services are responsible for the same thing such as logging, caching, authentication etc. It makes sense to offload it to GW.
There’re commercial or OSS products that support this scenario.
Azure App GW, Nginx, HA proxy, Traefik ( https://docs.traefik.io/) are good examples
OpenID Connect for consumer services, LDAP for enterprise
Fat gateway is an anti-pattern. Too much domain knowledge in GW becomes a blocker for fast deployment.That’s the mistake we made in SOA.
Gateway can be SPOF or perf bottleneck. That’s what happened at Pockemon GO lanuch event.
This slide has list of challenges rather than practices. I want to emphasize how important the networking is in MSA.
If there’re 100s of service each exposing endpoint, it’s hard to discover, load balance, protect, etc.
If you rotate this picture 90 degrees clock wise, it’ll be clear.
Especially, N-S requests becomes lots of E-W calls. We’ll see lots of East – West chattiness
Serialization-deserialization becomes performance overhead. Protobuf, Avro, Json, etc.
Centralized LB vs. decentralized LB (Service Fabric), Central one has better knowledge about state, decentralized one is handling distribution.
100s of services have different lifecycle, the destination of the service call may not be up and running. That’s why using message broker makes lots of sense because it keeps requests as messages while the destination is down. Then they’ll be processed afterwards.
When you update API, make sure it’s backward compatible. Or you can have 2 versions running SxS and gradually migrate from old version to new. There’re a few API versioning techniques such as using URL, query string, header etc. Choose the right one and use it consistently across all services.
Since IP address per container is masqueraded by default, NVA can’t protect them.
REST.LI: Framework for RESTful API used by LinkedIn
Thrift: Framework for cross-language RPC
Let’s say a tenant can create survey up to 100.
When they create a new one, we need to check if it’s still < 100. But directly accessing data in different service is anti-pattern. How can we deal with this situation?
One way is to replicate data from other service but it’s anti-pattern fro the same reason.
So the right solution is to access tenant’s data through tenant service.
Another scenario is where we need atomic operation. Let’s say when you create a new survey, the survey count needs to be incremented as atomic operation. How can we do this?
In order to make them atomic, DB write and sending msg needs to be in a single trx.
Instead, update 2 DB (Order, Order Event) as a single trx, then you’re safe to send a msg.
Reporting and analysis are very difficult workload in terms of data management.
Survey and Survey analysis obviously need to access the same data survey. But it’s not good in terms of dependency management. So instead we should separate read model from write. CQRS makes sense because most likely analysis needs only a subset of survey data schema so we can optimize read model to analysis workload.
Using transaction log or event sourcing is another option. There’re OSS components that supports this scenario.
Since it’s highly distributed, most likely one transaction requires multiple operations across services w/o DTC.
Serealizability and ACID is not longer relevant in the cloud. I don’t want to talk about CAP theorem because we all know that.
How can we deal with partial failure?
Instead of ensure consistency at DB operation level, we make the system state consistent at business level.
So in this case, the DB still look inconsistent, because we don’t roll back but system state is fine.
It may look easy but it’s not. You need to manage retry/timeout of each operation and manage the state of entire workflow. You also have to make sure no more than one worker will process the same order
SAS pattern is a good example of implementing this scenario.
http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
Correlating distributed transactions
Sidecar is a special container that is collocated with main container. It’s deployed into different cgroup but within the same namespace as main container so it can access the main service for monitoring.
Zipkin, Open tracing
APM tools like New Relic, Splunk etc.
Zipkin, Open tracing to correlate transactions across network boundary is the key.
They analyze the sampling of calls
https://www.youtube.com/watch?v=Q4nniyAarbs
There’re a number of options that you can choose from to implement MSA on Azure.
ACS lets you provision a cluster using DC/OS, Docker Swarm or Kubernetes.
Service Fabric is another Microsoft offering for hosting MSA
If you want to go down serverless path, then Azure functions is the right one for you. It becomes GA yesterday.
Docker cloud is the service from Docker. You can choose a provider from Azure, AWS, digital ocean etc.
You can provision VMs and install Docker yourself
App Service is another PaaS from MSFT
Docker streamlines deployment, isolation, standardize API (environment valiables, networking) for applications
Dev/Test benefit
Container is the standard format to host apps, that’s it.
The critical part is the orchestration. It’s very competitive area right now.
There’re Kubernetes, DC/OS, Docker Swarm, Nomad, now Hyper.sh is getting popular.
When I started learning containers a couple of years ago, I was always wondering which service does what?
From logical point of view there’s a set of components in the container orchestration.
You can register your container image into public/private registry. Scan the image to validate security policy etc.
Master node takes care of cluster management such as scheduling, recycling, deployment
It works with cluster state store which know what’s running where and who’s the leader
Requests from users would go through gateway and load balanced and routed to the service
Actual services are running on the app host
Minimum 5 node cluster
Each node can have multiple services running
There’s no dedicated master node. Every node acts as master as well as application host and possibly GW
Advanced features such as reliable collection, actors, rolling upgrade etc.
We started SF guidance a month ago, I wanted to share something but it’s still pre-mature so plz stay tuned.
When we migrate monolith to MS, Big bang approach wouldn’t work well
But even incremental migration is a challenge
How old monolith app can talk to the new microservices and vice versa?
How users can reach to the right service? They don’t know if it’s already migrated or not.
(Many folks recommend to start with monolith then migrate to MSA)
Strangler is the stuff that covers the tree, so you don’t see what’s inside.
The problem that this pattern solve is this.
Users used to access this feature in the old app but now it’s moved in to the new app.
We use it as analogy here. From outside the system, users don’t see what’s going on inside the system.
This is a 60 min summary of what MSA is and how to design it.
There’re numerous great materials. These are best ones among them.