Comparing JVM Web Frameworks - February 2014Matt Raible
My Comparing JVM Web Frameworks talk as presented at Denver's Open Source User Group (@dosug) and vJUG (@virtualjug). Covers the history of web frameworks as well as various methods for choosing one. Video on YouTube at https://www.youtube.com/watch?v=ygW8fJVlDxQ.
Blazing Fast, Pure Effects without Monads — LambdaConf 2018John De Goes
Effect monads like IO are the way functional programmers interact with the real world. Yet, monadic effects in programming languages like Scala often perform poorly compared to their Haskell counterparts—as much as 10x slower in some benchmarks. In this presentation, John A. De Goes, author of the Scalaz 8 effect system, dredges up an old paper to cast new light on the question of how to model effects, and comes to the surprising conclusion that in Scala, monads may not be the fastest way to model purely functional effects. Join John as he shows a new model of effects that offers performance improvements without sacrificing the wonderful purity that functional programmers rely on to reason about their software.
Kerberos is the system which underpins the vast majority of strong authentication across the Apache HBase/Hadoop application stack. Kerberos errors have brought many to their knees and it is often referred to as “black magic” or “the dark arts”; a long-standing joke that there are so few who understand how it works. This talk will cover the types of problems that Kerberos solves and doesn’t solve for HBase, decrypt some jargon on related libraries and technology that enable Kerberos authentication in HBase and Hadoop, and distill some basic takeaways designed to ease users in developing an application that can securely communicate with a “kerberized” HBase installation.
오픈소스 검색엔진인 Elasticsearch 어떻게 저장하고 조회하는지 검색엔진의 개념에 대해서 간단히 살펴보고, Node.js 로 구현된 아주 간단한 예제를 소개합니다.
- 검색엔진과 Elasticsearch 소개
- Elasticsearch에서의 색인
- Elasticsearch에서의 조회
- Node.js 로 구현된 예제 소개
* 자바카페
자바카페 페이스북 : https://www.facebook.com/groups/javacafe/
자바카페 기술 블로그 : http://tech.javacafe.io/
Spring integration을 통해_살펴본_메시징_세계Wangeun Lee
[스프링캠프 2015] Spring Integration을 통해 살펴본 메시징 세계 발표자료 입니다.
예제 소스 저장소는 프리젠테이션 안에 링크 걸어놨습니다.
감사합니다.
-------------------------------------------------------------------
우리는 늘 누군가와 소통(Communication)을 합니다. 소통을 통하여 누군가에게 일을 시키기도 하고 내가 일을 받기도 합니다. 애플리케이션도 마찬가지로 이기종간의 애플리케이션끼리 데이터로 소통을 하며 할 일을 서로 분산 처리할 상황이 발생하기도 합니다.
이런 분산 처리 이전에는 소통이 전제되어야 합니다. 애플리케이션 간 소통에 대한 고민은 선구자들에 의해 Enterprise Integration Patterns로 탄생되었으며 Spring에서도 그 패턴화의 추상화 일원으로 Spring Integration을 탄생시켰습니다.
이 강연에서는 Spring Integration을 통해 애플리케이션 간에 어떻게 쉽고 편하게(?) 소통을 할 수 있게 되었는지 살펴보며 예제와 사례를 통해 Spring Integration 입문에 도움을 주고자 합니다.
The Functional Programming Triad of Map, Filter and FoldPhilip Schwarz
This slide deck is my homage to SICP, the book which first introduced me to the Functional Programming triad of map, filter and fold.
It was during my Computer Science degree that a fellow student gave me a copy of the first edition, not long after the book came out.
I have not yet come across a better introduction to these three functions.
The upcoming slides are closely based on the second edition of the book, a free online copy of which can be found here:
https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html.
Download for original image quality.
Errata:
slide 20: the Clojure map function is in fact the Scheme one repeated - see code below for correction.
Scheme code: https://github.com/philipschwarz/the-fp-triad-of-map-filter-and-fold-scheme
Clojure code: https://github.com/philipschwarz/the-fp-triad-of-map-filter-and-fold-clojure
Introduces the functional programming ideas of Functor, Apply, Applicative And Monad. Shows how to implement each in Scala with Scalaz and how to validate the implementation using property based test using specs2 and scalacheck.
Comparing JVM Web Frameworks - February 2014Matt Raible
My Comparing JVM Web Frameworks talk as presented at Denver's Open Source User Group (@dosug) and vJUG (@virtualjug). Covers the history of web frameworks as well as various methods for choosing one. Video on YouTube at https://www.youtube.com/watch?v=ygW8fJVlDxQ.
Blazing Fast, Pure Effects without Monads — LambdaConf 2018John De Goes
Effect monads like IO are the way functional programmers interact with the real world. Yet, monadic effects in programming languages like Scala often perform poorly compared to their Haskell counterparts—as much as 10x slower in some benchmarks. In this presentation, John A. De Goes, author of the Scalaz 8 effect system, dredges up an old paper to cast new light on the question of how to model effects, and comes to the surprising conclusion that in Scala, monads may not be the fastest way to model purely functional effects. Join John as he shows a new model of effects that offers performance improvements without sacrificing the wonderful purity that functional programmers rely on to reason about their software.
Kerberos is the system which underpins the vast majority of strong authentication across the Apache HBase/Hadoop application stack. Kerberos errors have brought many to their knees and it is often referred to as “black magic” or “the dark arts”; a long-standing joke that there are so few who understand how it works. This talk will cover the types of problems that Kerberos solves and doesn’t solve for HBase, decrypt some jargon on related libraries and technology that enable Kerberos authentication in HBase and Hadoop, and distill some basic takeaways designed to ease users in developing an application that can securely communicate with a “kerberized” HBase installation.
오픈소스 검색엔진인 Elasticsearch 어떻게 저장하고 조회하는지 검색엔진의 개념에 대해서 간단히 살펴보고, Node.js 로 구현된 아주 간단한 예제를 소개합니다.
- 검색엔진과 Elasticsearch 소개
- Elasticsearch에서의 색인
- Elasticsearch에서의 조회
- Node.js 로 구현된 예제 소개
* 자바카페
자바카페 페이스북 : https://www.facebook.com/groups/javacafe/
자바카페 기술 블로그 : http://tech.javacafe.io/
Spring integration을 통해_살펴본_메시징_세계Wangeun Lee
[스프링캠프 2015] Spring Integration을 통해 살펴본 메시징 세계 발표자료 입니다.
예제 소스 저장소는 프리젠테이션 안에 링크 걸어놨습니다.
감사합니다.
-------------------------------------------------------------------
우리는 늘 누군가와 소통(Communication)을 합니다. 소통을 통하여 누군가에게 일을 시키기도 하고 내가 일을 받기도 합니다. 애플리케이션도 마찬가지로 이기종간의 애플리케이션끼리 데이터로 소통을 하며 할 일을 서로 분산 처리할 상황이 발생하기도 합니다.
이런 분산 처리 이전에는 소통이 전제되어야 합니다. 애플리케이션 간 소통에 대한 고민은 선구자들에 의해 Enterprise Integration Patterns로 탄생되었으며 Spring에서도 그 패턴화의 추상화 일원으로 Spring Integration을 탄생시켰습니다.
이 강연에서는 Spring Integration을 통해 애플리케이션 간에 어떻게 쉽고 편하게(?) 소통을 할 수 있게 되었는지 살펴보며 예제와 사례를 통해 Spring Integration 입문에 도움을 주고자 합니다.
The Functional Programming Triad of Map, Filter and FoldPhilip Schwarz
This slide deck is my homage to SICP, the book which first introduced me to the Functional Programming triad of map, filter and fold.
It was during my Computer Science degree that a fellow student gave me a copy of the first edition, not long after the book came out.
I have not yet come across a better introduction to these three functions.
The upcoming slides are closely based on the second edition of the book, a free online copy of which can be found here:
https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html.
Download for original image quality.
Errata:
slide 20: the Clojure map function is in fact the Scheme one repeated - see code below for correction.
Scheme code: https://github.com/philipschwarz/the-fp-triad-of-map-filter-and-fold-scheme
Clojure code: https://github.com/philipschwarz/the-fp-triad-of-map-filter-and-fold-clojure
Introduces the functional programming ideas of Functor, Apply, Applicative And Monad. Shows how to implement each in Scala with Scalaz and how to validate the implementation using property based test using specs2 and scalacheck.
Asynchronous API in Java8, how to use CompletableFutureJosé Paumard
Slides of my talk as Devoxx 2015. How to set up asynchronous data processing pipelines using the CompletionStage / CompletableFuture API, including how to control threads and how to handle exceptions.
Tutorial on developing a Solr search component pluginsearchbox-com
In this set of slides we give a step by step tutorial on how to develop a fully functional solr search component plugin. Additionally we provide links to full source code which can be used as a template to rapidly start creating your own search components.
Spring Framework Petclinic sample applicationAntoine Rey
Spring Petclinic is a sample application that has been designed to show how the Spring Framework can be used to build simple but powerful database-oriented applications.
The fork named Spring Framework Petclinic maintains a version both with a plain old Spring Framework configuration and a 3-layer architecture (i.e. presentation --> service --> repository).
Cost-based Query Optimization in Apache Phoenix using Apache CalciteJulian Hyde
This talk, given by Maryann Xue and Julian Hyde at Hadoop Summit, San Jose on June 30th, 2016, describes how we re-engineered Apache Phoenix with a cost-based optimizer based on Apache Calcite.
Apache Phoenix has rapidly become a workhorse in many organizations, providing a convenient standard SQL interface to HBase suitable for a wide variety of workloads from transactions to ETL and analytics. But Phoenix's initial query optimizer was based on static optimization procedures and thus could not choose between several potential plans or indices based on cost metrics.
We describe how we rebuilt Phoenix's parser and query optimizer using the Calcite framework, improving Phoenix's performance and SQL compliance. The new architecture uses relational algebra as an intermediate language, and this enables you to switch in other engines, especially those also based on Calcite. As an example of this, we demonstrate querying a Phoenix database via Apache Drill.
Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (DAT321) ...Amazon Web Services
Come to this session to learn how Amazon DynamoDB was built as the hyper-scale database for internet-scale applications. In January 2012, Amazon launched DynamoDB, a cloud-based NoSQL database service designed from the ground up to support extreme scale, with the security, availability, performance, and manageability needed to run mission-critical workloads. This session discloses for the first time the underpinnings of DynamoDB, and how we run a fully managed nonrelational database used by more than 100,000 customers. We cover the underlying technical aspects of how an application works with DynamoDB for authentication, metadata, storage nodes, streams, backup, and global replication.
In the session, we discussed the End-to-end working of Apache Airflow that mainly focused on "Why What and How" factors. It includes the DAG creation/implementation, Architecture, pros & cons. It also includes how the DAG is created for scheduling the Job and what all steps are required to create the DAG using python script & finally with the working demo.
Tree-like data relationships are common, but working with trees in SQL usually requires awkward recursive queries. This talk describes alternative solutions in SQL, including:
- Adjacency List
- Path Enumeration
- Nested Sets
- Closure Table
Code examples will show using these designs in PHP, and offer guidelines for choosing one design over another.
In this presentation, we are going to discuss how elasticsearch handles the various operations like insert, update, delete. We would also cover what is an inverted index and how segment merging works.
Developing Event-driven Microservices with Event Sourcing & CQRS (gotoams)Chris Richardson
Modern, cloud-native applications typically use a microservices architecture in conjunction with NoSQL and/or sharded relational databases. However, in order to successfully use this approach you need to solve some distributed data management problems including how to maintain consistency between multiple databases without using 2PC.
In this talk you will learn more about these issues and how to solve them by using an event-driven architecture. We will describe how event sourcing and Command Query Responsibility Separation (CQRS) are a great way to realize an event-driven architecture. You will learn about a simple yet powerful approach for building, modern, scalable applications.
Introduction to Event Sourcing and Challenges such as consistency, validation and concurrent updates.
The talk has been delivered at the Microservice Meetup in Munich.
Asynchronous API in Java8, how to use CompletableFutureJosé Paumard
Slides of my talk as Devoxx 2015. How to set up asynchronous data processing pipelines using the CompletionStage / CompletableFuture API, including how to control threads and how to handle exceptions.
Tutorial on developing a Solr search component pluginsearchbox-com
In this set of slides we give a step by step tutorial on how to develop a fully functional solr search component plugin. Additionally we provide links to full source code which can be used as a template to rapidly start creating your own search components.
Spring Framework Petclinic sample applicationAntoine Rey
Spring Petclinic is a sample application that has been designed to show how the Spring Framework can be used to build simple but powerful database-oriented applications.
The fork named Spring Framework Petclinic maintains a version both with a plain old Spring Framework configuration and a 3-layer architecture (i.e. presentation --> service --> repository).
Cost-based Query Optimization in Apache Phoenix using Apache CalciteJulian Hyde
This talk, given by Maryann Xue and Julian Hyde at Hadoop Summit, San Jose on June 30th, 2016, describes how we re-engineered Apache Phoenix with a cost-based optimizer based on Apache Calcite.
Apache Phoenix has rapidly become a workhorse in many organizations, providing a convenient standard SQL interface to HBase suitable for a wide variety of workloads from transactions to ETL and analytics. But Phoenix's initial query optimizer was based on static optimization procedures and thus could not choose between several potential plans or indices based on cost metrics.
We describe how we rebuilt Phoenix's parser and query optimizer using the Calcite framework, improving Phoenix's performance and SQL compliance. The new architecture uses relational algebra as an intermediate language, and this enables you to switch in other engines, especially those also based on Calcite. As an example of this, we demonstrate querying a Phoenix database via Apache Drill.
Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (DAT321) ...Amazon Web Services
Come to this session to learn how Amazon DynamoDB was built as the hyper-scale database for internet-scale applications. In January 2012, Amazon launched DynamoDB, a cloud-based NoSQL database service designed from the ground up to support extreme scale, with the security, availability, performance, and manageability needed to run mission-critical workloads. This session discloses for the first time the underpinnings of DynamoDB, and how we run a fully managed nonrelational database used by more than 100,000 customers. We cover the underlying technical aspects of how an application works with DynamoDB for authentication, metadata, storage nodes, streams, backup, and global replication.
In the session, we discussed the End-to-end working of Apache Airflow that mainly focused on "Why What and How" factors. It includes the DAG creation/implementation, Architecture, pros & cons. It also includes how the DAG is created for scheduling the Job and what all steps are required to create the DAG using python script & finally with the working demo.
Tree-like data relationships are common, but working with trees in SQL usually requires awkward recursive queries. This talk describes alternative solutions in SQL, including:
- Adjacency List
- Path Enumeration
- Nested Sets
- Closure Table
Code examples will show using these designs in PHP, and offer guidelines for choosing one design over another.
In this presentation, we are going to discuss how elasticsearch handles the various operations like insert, update, delete. We would also cover what is an inverted index and how segment merging works.
Developing Event-driven Microservices with Event Sourcing & CQRS (gotoams)Chris Richardson
Modern, cloud-native applications typically use a microservices architecture in conjunction with NoSQL and/or sharded relational databases. However, in order to successfully use this approach you need to solve some distributed data management problems including how to maintain consistency between multiple databases without using 2PC.
In this talk you will learn more about these issues and how to solve them by using an event-driven architecture. We will describe how event sourcing and Command Query Responsibility Separation (CQRS) are a great way to realize an event-driven architecture. You will learn about a simple yet powerful approach for building, modern, scalable applications.
Introduction to Event Sourcing and Challenges such as consistency, validation and concurrent updates.
The talk has been delivered at the Microservice Meetup in Munich.
Modern HA applications in nowadays are developed with set of small focused and discrete Microservices. It's a trending concept and opens/solves questions like maintenance, scaling, live-deployments, security, fault-tolerance etc.
While we’re drawing ever closer to Java 9, and even hearing about features in Java 10, it’s also true that many of us are still working with an older version. Even if your project has technically adopted Java 8, and even if you’re using it when coding new features, it’s likely the majority of your code base is still not making the most of what’s available in Java 8 - features like Lambda Expressions, the Streams API, and new Date/Time.
In this presentation, Trisha:
- Highlights some of the benefits of using Java 8 - after all, you’ll probably have to persuade The Management that tampering with existing code is worthwhile
- Demonstrates how to identify areas of code that can be updated to use Java 8 features
- Shows how to automatically refactor your code to make use of features like lambdas and streams.
- Covers some of the pros and cons of using the new features - including suggestions of when refactoring may NOT be the best idea.
Why Reactive Architecture Will Take Over The World (and why we should be wary...Steve Pember
The natural tendency for application developers is to construct their code in a procedural, monolithic pattern. Veteran Developers know that this leads to error prone, unscalable, slow software – yet it is alarmingly prevalent. There have been several architectural patterns that have risen over the years which have attempted to mitigate this problem. We’ve heard of Service Oriented Architecture, Integration Patterns, and Event-Driven Systems, but the Reactive pattern has the best chance for success.
In this talk I will discuss the tenants of the Reactive Pattern and the importance of moving away from Monolithic architectures into Reactive. We will examine Spring Integration and the Grails Async features (along with Netty and RabbitMQ) in order to show they can quickly and effectively help your application to become Reactive. Finally, I will argue that the JVM is the best foundation currently for this architecture – but that if we’re not careful, NodeJS may be the most popular.
Introduction to Amazon Web Services - How to Scale your Next Idea on AWS : A ...Amazon Web Services
Building powerful web applications in the AWS Cloud : A Love Story, Design patterns in web-based cloud architecture, Jinesh Varia gave this talk at Cloud Connect and several other places
http://aws.typepad.com/aws/2011/03/building-powerful-web-applications-in-the-aws-cloud-a-love-story.html
MicroServices at Netflix - challenges of scaleSudhir Tonse
MicroServices has caught on as the design pattern of choice for many companies at scale. While MicroServices and SOA in general have many positives compared to Monolithic apps, it does come with its own challenges - especially when running at scale. These slides were for a 15 min Meetup talk hosted at Cisco
WinOps Conf 2016 - Matteo Emili - Development and QA Dilemmas in DevOpsWinOps Conf
The quick rise of Continuous Delivery in the enterprise means that common problems are often approached the other way round. Concepts like Feature Flags and Testing In Production caused several headaches to developers and QA engineers, especially where they have a wealth of experience about traditional development.
There are some challenges and approaches which are very common, and they still scare newcomers. Let's have a look at a few of these, with the most common solutions.
Do you have a monolith? If so, is it majestic? Or is it broken and preventing you from scaling your application and your business?
Monoliths have earned a bad reputation in software architecture design circles for being difficult to maintain and operating on silos of knowledge. However, they aren't all bad. The key is knowing when to use a monolith, and when it is time re-factor and scale up by going small.
At some point, the code you write today will be deleted and replaced with something new. This talk will discuss the life cycle of a large code base, and how to manage it over time to accommodate rewrites, giving examples from a major rewrite of the Firefox build and release pipeline over the last two years. You'll learn how to replace components of a running distributed system while keeping it operational, the proverbial replacing the wing of an airplane in flight.
Getting software released to users can be risky, time-consuming and painful. The solution is the ability to deliver reliable software continuously through build, test and deployment automation, and through improved collaboration between developers, testers and operations. In this tutorial we will present principles and technical practices that enable teams to incrementally deliver software of high quality and value into production whenever they want, and extremely fast. The size of the project or the complexity of its code base does not matter.
In the first half of the tutorial we will introduce the concepts of continuous delivery, through continuous integration; and automation of the build, test and deployment process. We will also go through som basic principles and patterns for building automatable applications (architecture). We will cover experiences on team collaboration patterns and lastly; techniques for solving tasks such as an easy and comprehendible version control strategy.
The second half of the tutorial we will be working with automated provisioning of agile infrastructure, including the use of tools (puppet) to automate the management of testing and production environments. We will go through some scripting lessons examplifying how to implement zero-downtime deploys (… and rollback – if something goes wrong!), with examples in both bash and Ruby. Along with controlling the start, stop, restart lifecycles during deploys, we will also show some simple techniques for backups, logging, error handling, monitoring and verification of application health that can make the automation more robust.
We will also use servers "in the cloud" to demonstrate different techniques, and we hope to make it a fun day and to deliver software (examples) several times throughout the workshop.
Required knowledge: Agile/Lean basics, Linux basics, version control basics, maven basics.
stackconf 2023 | Better Living by Changing Less – IncrativeOps by Michael Cot...NETWAYS
DevOps has always been about dramatic changes to improve IT. You don’t only need to use a different set of tools, you need to change your entire IT culture! It’s all exhausting, really. Worse, this imperative to change never goes away. Will we ever actually be done and “be like Google”? Instead of carrying the flag of “change or die,” this talk proposes an alternate, more practical, sustainable, and comforting approach to improving: IncrativeOps.
Moving to Microservices with the Help of Distributed TracesKP Kaiser
Moving away from a monolith to a microservices architecture is a process fraught with hidden challenges. There's legacy code, infrastructure, and organizational processes that all need to change, in order to make the switch successful.
But microservices come with a huge increase in infrastructure complexity. We'll see how distributed traces empower developers to work with greater autonomy, in increasingly complex deployment environments.
Keynote- We're going wrong: Choosing the web's future. Peter Paul KochFuture Insights
From FOWA London 2015
Web developers and browser vendors are trying too hard to emulate native apps; in vain, PPK says, because we can't out-native native. Meanwhile this quest for native emulation has a host of undesirable by-effects: too many new browser features that need too many new (and not always performant) tools to create polyfills, which cause too many people to think they only need to understand the tools in order to be a web developer. We're going wrong. We should take some time to figure out what the web is for, how we can have a successful web ecosystem next to, but not in competition with, native ecosystems, and how we should explain what web development is to Java developers and others who come from a non-web background. We need time to think.
Slides from my DevOpsExpo London talk "From oops to NoOps".
They tell you in these conferences that DevOps is not about tools, but about culture. And they are partially right. I am going to tell you that it’s not only about culture or tools but also abstractions.
It is a lot about how you see software and its value. About our mental model of what software is: how it runs, evolves, and interacts with the other facets of an enterprise.
We used to view software as code. As a state of code. Now we think about software as change, as a flow. A dynamic system where people, machines, and processes interact continuously.
At Platform.sh we spend a bunch of time asking ourselves not “How do you build?” - or even “How do you build consistently?” - but rather “What does it mean to consistently build in a world where change is good?” A world that lets you push security fixes into production as soon as they’re available because you don’t want to be an Equifax but you do want stability.
In this presentation, I will go over what we think software is and why having the right ideas about software will help you get your culture right and your tooling aligned, as well as gain in productivity, and general happiness and well-being.
Also, keep in mind, this is, of course, just my list and I deliberately wanted to keep it short because if I specified 20 trends here, I'm not sure if they're really all trends.
A brownbag presentation at IPC media in London about the need to use libraries to make web development much less random and more professional. Get the audio at: http://www.archive.org/details/ProfessionalWebDevelopmentWithLibraries
These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evans' prescient book, Domain-Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And although there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I‘ll show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.
Similar to Reactive Microservice Architecture with Groovy and Grails (20)
Spring I_O 2024 - Flexible Spring with Event Sourcing.pptxSteve Pember
Event Sourcing is a modern but non-trivial data model for building scalable and powerful systems. Instead of mapping a single Entity to a single row in a datastore, in an Event Sourced system we persist all changes for an Entity in an append-only journal. This design provides a wealth of benefits: a built-in Audit Trail, Time-Based reporting, powerful Error Recovery, and more. It creates flexible, scalable systems and can easily evolve to meet changing organizational demands. That is, once you have some experience with it. Event Sourcing is straightforward in concept, but it does bring additional complexity and a learning curve that can be intimidating. People coming from traditional ORM systems often wonder: how does one model relations between Entities? How is Optimistic Locking handled? What about datastore constraints?
Based on over eight years of experience with building ES systems in Spring applications, we will demonstrate the basics of Event Sourcing and some of the common patterns. We will see how simple it can be to model events with available tools like Spring Data JPA, JOOQ, and the integration between Spring and Axon. We’ll walk through sample code in an application that demonstrates many of these techniques. However, it’s also not strictly about the code; we’ll see how a process called Event Modeling can be a powerful design tool to align Subject Matter Experts, Product, and Engineering. Attendees will leave with an understanding of the basic Event Sourcing patterns, and hopefully a desire to start creating their own Journals.
Anatomy of a Spring Boot App with Clean Architecture - Spring I/O 2023Steve Pember
In this presentation we will present the general philosophy of Clean Architecture, Hexagonal Architecture, and Ports & Adapters: discussing why these approaches are useful and general guidelines for introducing them to your code. Chiefly, we will show how to implement these patterns within your Spring (Boot) Applications. Through a publicly available reference app, we will demonstrate what these concepts can look like within Spring and walkthrough a handful of scenarios: isolating core business logic, ease of testing, and adding a new feature or two.
SACon 2019 - Surviving in a Microservices EnvironmentSteve Pember
Many presentations on microservices offer a high-level view of the architecture; rarely do you hear what it’s like to work in such an environment. Stephen Pember shares his experience migrating from a monolith to microservices across several companies, highlighting the mistakes made along the way and offering advice.
Surviving in a Microservices environment -abridgedSteve Pember
Many presentations on Microservices offer a high-level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some considerable DevOps work and start learning about deployment pipelines, metrics, and logging.
Don’t panic. In this presentation we’ll discuss what we learned over the past four years by highlighting our mistakes. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll see how team communication is more important than one might realize. Most importantly, we’ll show how - while an individual service is simple - the infrastructure demands are now much more complicated: your organization will need to introduce and become increasingly dependent on various technologies, procedures, and tools - ranging from the ELK stack to Grafana to Kubernetes. Lastly, you’ll come away with the understanding that your resident SREs will become the most valued members of your team.
Over the past few years, Gradle has become a popular build tool in the JVM space. This is not surprising, considering the power and the features it brings, compared with its competitors. However, one thing Gradle lacks is history and the collective knowledge at the same level of other alternatives: how does one organize a Gradle project in an ‘idiomatic’ fashion?
We feel that we’ve put together a decent build pipeline for each of our microservices over the years, and each one starts with their build.gradle file(s). We’d like to share it, although we’re not sure if it’s the ‘correct’ way.
In this talk, we’ll walk through a sample project structure and build process. We’ll discuss the various checks and tools we use (e.g. Sonar, CodeNarc, Jenkins) at each step of the build. We’ll explain how each of the components in the process work for us, and share samples of our Groovy scripts. Most importantly, though, we’d like to hear what the audience are using in their builds!
Many presentations on Microservices offer a high level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some DevOps work and start learning about deployment pipelines, metrics, and logging.
Don’t panic. In this presentation we’ll discuss what we, at ThirdChannel, learned over the past four years. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent on various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about team communication and organization… and how they are likely the most important tool for surviving a Microservices development team.
Reactive applications & reactive programming result in flexible, concise, performant code and are a superior alternative to the old thread-based programming model. The reactive approach has gained popularity for a simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in reactive terms, particularly when one realizes that we must be Reactive up and down the entire programming stack.
In this talk we’ll explore what it means to be ‘Reactive’. We’ll examine some of the more interesting tools available to us, some of which come from the Groovy community. Specifically we’ll cover Ratpack, RxGroovy, React, and RabbitMq - along with examples and a sample implementation. We’ll demonstrate how effectively they can work together at each level of the stack - from the front end, to the back end, to handling http requests and message queue events - and how easy it can be to go Reactive all the way down.
Event storage offers many practical benefits to distributed systems providing complete state changes over time, but there are a number of challenges when building an event store mechanism. Stephen Pember explores some of the problems you may encounter and shares real-world patterns for working with event storage.
Harnessing Spark and Cassandra with GroovySteve Pember
This talk is an introduction to a powerful combination in the big data space: Apache Spark and Cassandra. Spark is a cluster-computing framework that allows users to perform calculations against resilient in-memory datasets using a functional programming interface. Cassandra is a linearly scalable, fault tolerant, decentralized datastore. These two technologies are complicated, but integrate well and provide such a level of utility that whole companies have formed around them.
In this talk we’ll learn how Spark and Cassandra can be leveraged within your Groovy Application: Spark normally asks for a Scala environment. We’ll talk about Spark and Cassandra from a high level and walk through code examples. We’ll discuss the pitfalls of working with these technologies - like modeling your data appropriately to ensure even distribution in Cassandra and general packaging woes with Spark - and ways to avoid them. Finally, we’ll explore how we at ThirdChannel are using these technologies.
Surviving in a microservices environmentSteve Pember
Many presentations on Microservices offer a high level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some DevOps work and start learning about deployment pipelines, metrics, and logging.
Don’t panic. In this presentation we’ll discuss what we learned over the past three years. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent on various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about team communication and organization... and how they are likely the most important tool for surviving a Microservices development team.
Surviving in a Microservices EnvironmentSteve Pember
Cloud Native Microservice architectures have become increasingly popular over the past few years, and for good reasons: smaller, efficient codebases, finely targeted scaling options, and the ability to do continuous deployment along with continuous integration, among others. All potentially very powerful features. However - as with most things - Microservices bring tradeoffs in terms of application complexity: working with an individual service is easy; overall application development becomes increasingly complex. Perhaps too complex for your average web application.
Many presentations on the Microservice phenomena offer either a high level view on what it is, compare and contrast it with the Monolith pattern, or discuss how to migrate from a Monolith to Microservices, but rarely does one hear what it’s like to actually work in such an environment. Frankly, it can be intimidating for someone accustomed to a traditional monolithic development experience. Individual services are somewhat trivial to develop, but now you suddenly have countless others to keep track of. You may become lost: with all these services, is anyone directing the overall development? You’ll become obsessed over how and when they communicate. You’ll have to start referring to the application on the whole as “the Platform”. It’ll soon become difficult or even impossible to run the whole Platform on a development laptop. You may even have to take on some DevOps work, and start learning about deployment pipelines, and whole new worlds of metrics and logging.
Don’t panic. In this presentation we’ll discuss what we learned working with a Microservice platform for the past three years. We’ll cover what to expect when joining a Microservice team and what the situation will look like as the team size grows. We’ll see how critical inter-service testing strategies are to the success of the team. We’ll examine what a development lifecycle might look like for adding a new service, developing a new feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent and various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about communication, team organization strategies, and how they are likely the most important tool for surviving a Microservices development team.
An introduction to Reactive applications, Reactive Streams, and options for t...Steve Pember
The term “reactive” has lately become a buzzword, with a variety of definitions around the Web. When you hear “reactive,” what do you think of? Reactive Streams? The Reactive Manifesto? ReactJS? These terms may seem unrelated, but they share a common core concept.
Reactive applications and Reactive programming result in flexible, concise, performant code and are a superior alternative to the old, standard thread-based imperative programming model. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms due to how accustomed we’ve become to the imperative style.
Stephen Pember explores the various definitions of Reactive and Reactive programming with the goal of providing techniques for building efficient, scalable applications. Steve dives into the key concepts of Reactive Streams and examines some sample implementations—including how ThirdChannel is currently using reactive libraries in production code. Steve looks at some of the open source options available in the JVM—including Reactor, RxJava, and Ratpack—giving you an idea of where to begin with the reactive ecosystem. If Reactive is new to you, this should be an excellent introduction.
Are you tired of Hibernate? Is GORM is too heavy for your current project? Do you like having more control over your SQL? Do you like flexible DSLs? Try JOOQ!
JOOQ (Java Object Oriented Querying) is light-weight alternative to classic data access solutions or ORMs like Hibernate, JPA, JDBC, and GORM. JOOQ's goal is to give the developer a flexible DSL for building typesafe, database agnostic SQL queries, and attempts to convince the developer of a ‘database-first’ approach to building their application. In this talk we’ll quickly present an introduction to JOOQ from a high level, discuss its features, and see several examples of how we’re using JOOQ to great effect with many Spring Boot and Ratpack apps within our platform.
Reactive Streams and the Wide World of GroovySteve Pember
The concept of Reactive Streams (aka Reactive Extensions, Reactive Functional Programming, or simply Rx) has become increasingly popular recently, and with good reason. The Reactive Streams specification provides a universal abstraction for asynchronously processing data received across multiple sources (e.g. database, user input, third-party services), and includes mechanisms for controlling the rate at which data is received. This makes it a powerful tool within a Microservice platform. And did we mention that the Groovy lang community is quite involved?
In this talk we’ll explore the various features and concepts of Reactive Streams. We’ll talk about some typical use cases for Rx and more importantly, how to implement them. We’ll focus primarily on RxGroovy and Ratpack, then provide example implementations that show you how to get started with this powerful technique.
As businesses grow, so does the complexity of their software. New features, new models, and new background processes all continue to be added. . .and developers struggle to make sense of it all. Yet the end user demands a swift and functional experience when interacting with your application. It is paramount to be open to alternative patterns that help tame complex, high-demand services. Two such patterns are command-query responsibility segregation (CQRS) and event sourcing (ES).
Command-query responsibility segregation is an architectural pattern for user-facing applications that extends from the now standard Model-View-Controller (MVC) pattern and is an alternative to the CRUD pattern. At its core, CQRS is about changing how we think of and work with our data by introducing two types of models: all user actions become commands, and a read-only query model powers our views. Commands and queries are logistically separated, providing additional decoupling of our application. CQRS also calls for changes in how we store and structure our data.
Enter event sourcing. Instead of persisting the current state of our domain objects or entities, we record historical events about our data. The key advantage is that we can examine our application data at any point in time, rather than just the current state. This pattern changes how we persist and process our data but is surprisingly efficient.
While each of the two patterns can be used exclusively, they complement each other beautifully and facilitate the construction of decoupled, scalable applications or individual services. Stephen Pember explores the fundamentals of each pattern and offers several examples and demonstration code to show how one might actually go about implementing CQRS and ES. Steve discusses task-based UIs and domain-driven design as he outlines some of the advantages—and challenges—that ThirdChannel has seen when developing systems using CQRS and ES over the past year.
An Introduction to Reactive Application, Reactive Streams, and options for JVMSteve Pember
The term “reactive” has lately become a buzzword, with a variety of definitions around the Web. When you hear reactive, what do you think of? Reactive Streams? The Reactive Manifesto? ReactJS? These terms may seem unrelated, but they share a common core concept.
Reactive applications and reactive programming result in flexible, concise, performant code and are a superior alternative to the old standard thread-based imperative programming model. The reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in reactive terms due to how accustomed we’ve become to the imperative style.
Stephen Pember explores the various definitions of reactive and reactive programming with the goal of providing techniques for building efficient, scalable applications. Steve dives into the key concepts of Reactive Streams and examines some sample implementations—including how ThirdChannel is currently using reactive libraries in production code. Steve looks at some of the open source options available in the JVM—including Reactor, RxJava, and Ratpack—giving attendees an idea of where to begin with the reactive ecosystem. If reactive is new to you, this should be an excellent introduction.
Richer Data History with Event Sourcing (SpringOne 2GX 2015Steve Pember
A common pattern in application development is to build systems where the data is directly linked to the current state of the application; one row in the database equates to one entity’s current state. Only ever knowing the current state of the data is adequate for many systems, but imagine the possibilities if one had access to the state of the data at any point in time. Enter Event Sourcing: instead of persisting the current state of our Domain Objects or Entities, we record historical events about our data. This pattern changes how we persist and process our data, but is surprisingly lightweight. In this talk I will present the basic concepts of Event Sourcing and the positive effects it can have on analytics and performance. We’ll discuss how storing historical events provides extremely powerful views into our data at any point in time. We’ll see how naturally it couples with the Event-oriented world of modern Reactive systems, and how easily it can be implemented in Groovy. We’ll examine some practical use cases and example implementations in Ratpack. Event Sourcing will change how you think about your data.
Springone2gx 2015 Reactive Options for GroovySteve Pember
Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms. It doesn’t help that the descriptions around the web can be contradictory and the library documentation can be obscure. In this talk, we’ll explore the concepts of Reactive and Reactive Programming. We’ll demonstrate some of the useful Reactive functions and examine some practical implementations - including how we’re currently using Reactive libraries in production code. Most importantly, we’ll look at some of the open source options available to us in the Groovy community, including Reactor, RxJava, and Ratpack. If Reactive is new to you, this should be an excellent introduction.
Gr8conf US 2015 - Intro to Event Sourcing with GroovySteve Pember
As Grails developers we generally build systems where our data is directly linked to the current state of our application; one row in the database equates to one entity’s current state. Only ever knowing the current state of the data is adequate for many systems, but imagine the possibilities if one had access to the state of the data at any point in time.
Enter Event Sourcing: instead of persisting the current state of our Domain Objects, we store historical events about our data. This pattern changes how we store and process our data, but is surprisingly lightweight and performant. In this talk I will present the basic concepts of Event Sourcing and the positive effects it can have on analytics and performance. We’ll see how naturally it couples with the Event-oriented world of modern Reactive systems, and how easily it can be implemented in Groovy. We’ll examine some practical use cases and example implementations. Event Sourcing will change how you think about your data.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
2. We’ve got a journey ahead of us folks, over an hour.
I’ll stop periodically for questions.
Last session of the day, I know it’s a haul. We’re almost there.
3. Agenda:
• 1. Monolithic Apps Will Ruin You
• 2. Service Oriented Architecture and Microservices
• 3. Reactive Applications
• 4. Practical Development (Caveats)
• 5. Case Studies (Including 3C)
THIRDCHANNEL
3
While I will be talking about Reactive Applications with Groovy, there’s a good deal of information surrounding the approach that should be covered first.
From a high level, I’d group these points into the following topics:
1. Monolithic Apps are Evil and will Ruin You
2. Service Oriented and Microservice Architecture, specifically their benefits and when you would or wouldn’t want to use them
3.
5. Have you ever...
Gone through a major refactoring of your
application?
THIRDCHANNEL 5
6. Have you ever...
Gone on an ‘Archeological Expedition’ in
the codebase to add a new feature?
THIRDCHANNEL 6
7. Have you ever...
Thought “Why are there so many #@$!%
tables in this database?!”
THIRDCHANNEL 7
Have you ever been distraught at the number of joins needed to fetch a batch of records?
8. Have you ever...
Dreaded executing the test suite?
THIRDCHANNEL 8
-Who here has worked on a major project where the unit tests took longer than 15 minutes to run?
-30?
- Did you ever notice that developers tend to ignore running the tests when that happens? How was build stability?
- On the flip side, has anyone worked on a major project that had effectively NO tests?
9. These are all symptoms of a Monolithic application. If you laughed, I’m assuming that the answers were a ‘yes’.
11. -A monolithic app is: Single, logical executable or unit, often comprised of 3 components for a web app: the View layer (CSS/HTML/JS), the middle tier
(contains business logic) and the data storage.
-For example, here’s an example of an e-comm app: product browsing, catalog management, order processing, shopping cart
12. Monoliths Feel Natural
• Contains Everything
THIRDCHANNEL
12
If you’re just starting out with building an application, a Monolith feels natural
!
The Monolith Contains all application features and all logic necessary for handling a request within a single process.
13. THIRDCHANNEL 13
Your developers can generally run ANNNND test the entire app at once, on their laptops
14. Monoliths Feel Natural
• Contains Everything
• Minimum Viable Product can be reached quickly
THIRDCHANNEL
14
— Perhaps their most attractive feature, is that a development team - even a very small one - can reach the Minimum Viable Product very quickly.
15. Monoliths Feel Natural
• Contains Everything
• Minimum Viable Product can be reached quickly
• Single Deployment
THIRDCHANNEL
15
There’s only a single artifact to deploy, which makes deployment and DevOps incredibly easy! … (he says sarcastically)
16. Monolithic apps scale horizontally by deploying whole new instances of the monolith, probably behind a load
balancer.
!
This is wasteful, as we scale the entire application rather than just the portions that require it.
For example -> if we’re receiving a flood of requests to the Order Processing, we don’t need to scale the whole
thing
!
18. I generally regard these single, logical units as an Evil piece of software.
Like I said, it feels like the right thing to do… and they tempt you with how easy it is to in the beginning.
Why?
19. You start out strong, adding controllers here, domain objects, etc.
You can be blinded by early gains toward your first release that you become shortsighted and aren’t thinking towards the future.
20. As those Domains grow, you start adding relations all over the place.
Can you really look at a class or schema diagram like this and really think, “Yeah, that’s awesome. Nailed it.”?
-btw, this was the largest I could find on Google images. I’m sure we’ve all seen the massive versions of this that cover multiple pages, taped to the wall.
- If you ever have to tape to the wall, done something wrong
21. The Complexity of your application will soon become enormous.
!
Any gains you think you may have made at the beginning of the project will not continue, particularly once you start to attract users.
..And grow your team.
23. The ability to add new features, fix bugs, or resolve technical debt cannot scale with the size of the application. Throwing more developers at it also will not
help, they’ll just get in each others’ way.
- One of the best passive-aggressive statements I’ve seen
- Passive aggressively scrawled on the wall: You can’t make a baby in 1 month with 9 women.
24. -And trying to refactor anything? Forget it.
-I’ve seen it happen plenty of times: Your company will start out by creating a team to reimplement a feature or rebuild an application. Sounds good?
Eventually, this team will start taking too long. Soon enough, the managers will be screaming for updates or new features on the old app. So, you end up
with *two* teams, one maintaining the old app, while the other continues the rebuild AANNND maintains feature parity with the old system.
25. THIRDCHANNEL 25
As the size of your codebase increases, the computational complexity will exponentially increase and will have adverse effects on maintenance. This has
been known for some time; there’s been papers written on the subject. Although it’s difficult to accurately measure.
26. It can also just be downright miserable. Has anyone here ever opened their project, looked at the maze of controllers or domains - that seem to just
explode out at you when opening the folder - and… just give an exasperated sigh?
Toiling away on a project which is always growing… always broken… and never seems to get fixed. You work on a small piece all day and nothing ever
seems to get better? …This can have an adverse effect on developer morale and motivation.
27. This is such a misguided architecture, it makes you wonder how exactly we collectively ended up here.
28. I blame it largely at the feet of the large, popular web frameworks, e.g. Rails, Django, Grails.
!
Don’t get me wrong, they have their uses.
And yes, I see the … irony… in complaining about them while at a framework conference
!
29. But they’re touted as if they’re the magic cure for building your app or product; that your company should be
based entirely within a framework. You hear folks say, “Oh, what are you using in your startup?” “Why, We’re a
Ruby on Rails shop, obviously!”.
!I
argue that your framework choice is largely irrelevant (unless it’s Grails ;)! ). When people ask you “what
technology are you using?” the answer should be something like “Ugh, well, that’s difficult”.
31. Architecture Choice is More
Important Than Any
Framework*
*And we all know that only JVM languages should even be
considered
32. Questions so far?
• 1. Steve really hates Monolithic apps
!
• 2. Monolith Development will not scale
!
• 3. Architecture Choice > Frameworks
THIRDCHANNEL
32
So, to recap:
!!
Any questions?
35. With SOA, one would break up each feature into an individual component or service, and setup communication between each service over some direct
service calls. Eg SOAP or REST.
-Note that these calls are traditionally Synchronous over http, so it’s imperative that each node return as quickly as possible
36. This architecture keeps keeps the individual features easier to manage and keep track of, which reduces overall complexity dramatically as we can
examine each service in isolation, rather than one big code base
37. However, before I go into why that’s so important: SOA, specifically, is not without its own issues.
!
First, having that web of interconnected services can grow out of control. Having to configure service nodes so that each knows where the others are
located in the network can be cumbersome to manage.
38. ESB
THIRDCHANNEL 38
Furthermore, anecdotally, organizations tend to treat SOA differently and have different definitions for what, exactly, SOA is.
-In many cases, Enterprise Service Buses (or ESBs) have arisen to deal with complicated traffic. An ESB acts as a piece of middleware that ‘intelligently’
routes traffic to the appropriate server. Which sounds useful, except This adds an additional layer of complexity to an already complex approach,
especially if you’re rolling your own ESB.
-Often, I’ve seen clients that would hook up several monoliths together and call it SOA
-It’s terrible when these all come together.
39. The Rise of
Microservices
Given those pain points, I think that leads right into talking about Microservices, which is a buzzword you certainly couldn’t have escaped hewing about
after that keynote last night. And every other talk here at SpringOne
40. Microservices
• Distillation of SOA
THIRDCHANNEL
40
So what exactly is a Microservice architecture?
!I
firmly believe Microservices were born out of a desire to be more specific when we talk about Service Oriented Architecture.
!
41. If you look at what people are writing about the approach, you can see that it is clearly an attempt to be more focused about using services.
And, certainly, how we manage the teams working on them
!
42. Microservices
• Distillation of SOA
• Single Context
THIRDCHANNEL
42
A Microservice should be concerned with only one ‘context’. This helps to avoid having each service become a monolith on its own
43. Back to this example, here we’ve split up each of the specific components into their own bounded context.
!I
say “bounded context” because that’s an important metric. You may hear folks say “ A microservice needs to be under 1000ish total lines of code”. Or
something like that.
!
Which is Ridiculous. A microservice should surround a particular bounded context within your application. Meaning that it is the responsible for a
particular section of contiguous business logic… it’s the authoritative source on one ‘thing’.
44. Microservices
• Distillation of SOA
• Single Context
• Smart Services / Dumb Pipes
THIRDCHANNEL
44
-A Microservice Architecture emphasizes that communication between services be ‘dumb’.
-As opposed to ESBs, which can contain complex routing and even business logic
- Rather, keep all business logic contained within the relevant Service
45. Back to this example. Each service should communicate with each other via ‘dumb’ (as in, single-minded) methods.
For example, we could use straight up HTTP to talk between services.
Be “of the web”. Use Http Resources (HATEOAS anyone?) between services
46. Or, Use Message Brokers
Or, Preferably - in my opinion - Communicate between your services using an asynchronous Message Broker and Message Queues
!
There are several excellent ones that you can use. We could send quite a bit of time just talking about RabbitMQ
47. Message Brokers generally follow this pattern:
-Messages are routed through an EXCHANGE in to one or many queues.
-Messages are then plucked off the queue by an attached, waiting Consumer. Or, the first available if multiple are
attached.
49. -we’ve broken the features into individual applications and spun up one node per each
-connected the users’ cart to a queue, and our order processing into another queue
!
- the quickest win in doing just this is that now our application can place items in a users cart and take orders
*asynchronously*. Imagine a flurry of users ordering from you and you’re unable to take their money fast
enough.
- here, the order is placed on the queue and your users go back to browsing or purchasing more. This frees up
request threads in the front-end for other users as you’re not blocking on the billing component, which may
require expensive credit card operations.
50. Microservices
• Distillation of SOA
• Single Context
• Smart Services / Dumb Pipes
• RESTful Communications
THIRDCHANNEL
50
In a distributed system. One of the most ridiculous things you can do is try and share state across services.
Thus a core component of a microservices architecture is to NEVER share state
51. Attempting to keep shared state across distributed services WILL lead to madness.
You can certainly have mutable state *within* a service, but trying to sync that is just ridiculous.
As we were talking about before with the simple communication strategy: make REST a part of it
52. Microservices
• Distillation of SOA
• Single Context
• Smart Services / Dumb Pipes
• RESTful Communications
• Dedicated, Cross-Purpose Teams
THIRDCHANNEL
52
53. Teams in charge of a service should come from a variety of disciplines. Engineering, QA, Art & Design, Project Management, perhaps a deployment
engineer, etc.
! (If anyone laughs : Yes, I mixed Star Trek and Star Wars references.
54. Benefits of SOA & Microservices
Before I … eventually… get into some of the … caveats with this architecture,
Let me tempt you with why it’s great
!
Why would I want to do this?
55. Yay for Microservices
• It’s easier to reason about smaller codebases
THIRDCHANNEL
55
It’s dramatically easier to reason about smaller codebases
56. Each engineer should be able to understand and hold the majority of the service within their mind,.
!
Thus, when a defect occurs, it’s easier to know exactly where the problem code lies.
When a new feature is needed, it’s easier to know exactly where to build and how it will affect other components.
57. !
Maintenance and adding new features now becomes vastly easier. You’ll find that iterating on a particular service is much quicker, and it’s easier to
context shift when and if it’s time to work on another service.
58. Which results in rapid long-term
development
In addition, by focusing our developers into teams responsible for each service, this keeps them more focused and out of each others way. Which, again, is
a very common problem with monolithic apps. If you’re working on a monolith, how often are you getting merge conflicts?
59. Yay for Microservices
• It’s easier to reason about smaller codebases
• Easy To Scale / Deploy / Destroy
THIRDCHANNEL
59
60. -we’ve broken the features into individual applications and spun up one node per each
-connected the users’ cart to a queue, and our order processing into another queue
61. -suppose the cart and order processing start experiencing heavy load
- programatically spin up new instances to handle it
- Does everyone remember Andy Glover’s talk from yesterday? He had a thread on how rapidly iterating is the key to beating out your competitors.. and I
think, right here, is exactly what he was talking about…
-
62. Yay for Microservices
• It’s easier to reason about smaller codebases
• Easy To Scale / Destroy /Deploy
• Easy To Refactor
THIRDCHANNEL
62
63. Both in terms of adding new features, or removing old ones
! If we need to refactor a particular feature in a service… say, the inventory check when adding a product to a cart, I can do so without impacting the rest of
the application.
!
Further, if we decide to totally revamp our billing service (say we want to try out Ratpack), we can develop the new service quickly (as we’re starting with
something new) and slap it on the queue, again without directly impacting or interrupting the others.
!
A/B Testing: We could also compare our refactored billing service by having both old and new listen on the queue, then compare how effective the two
billing services are.
64. Yay for Microservices
• It’s easier to reason about smaller codebases
• Easy To Scale / Destroy /Deploy
• Easy To Refactor
• Right Tool for the Job
THIRDCHANNEL
64
-not every service needs use the same languages, frameworks
- With an SOA or Microservice approach, each service can be constructed with the technologies that best suit its context and functionality.
65. -If the main product browse / web interface is best suited for a standard web framework, like Grails… perfect
-What about the shopping cart? Maybe it should be built with a Redis Data source? No sweat
-How about the Order placement? Let’s use some Spring Boot, with some Spring Integration on a Postgres database.
66. Plus, I firmly believe that this helps to improve the morale of your developers.
- When it’s time for a new service, people get generally excited.
-Get to work with something a bit new
-Design a new project
-There’s contentment in that
67. Yay for Microservices
• It’s easier to reason about smaller codebases
• Easy To Scale / Destroy /Deploy
• Easy To Refactor
• Right Tool for the Job
• History Is Isolated
THIRDCHANNEL
67
Because each service is kept as a separate product, it should ideally have it’s own repository. Therefore, one nice added effect is that each product now
has it’s own isolated revision history
68. Yay for Microservices
• It’s easier to reason about smaller codebases
• Easy To Scale / Destroy /Deploy
• Easy To Refactor
• Right Tool for the Job
• History Is Isolated
• Mitigates Conway’s Law
THIRDCHANNEL
68
Has anyone heard of Conway’s law?
69. Conway’s Law
“organizations which design systems ... are constrained
to produce designs which are copies of the
communication structures of these organizations”
-Melvin Conway, 1968
http://en.wikipedia.org/wiki/Conway's_law
THIRDCHANNEL 69
It’s a tongue-in-cheek quote from programmer Melvin Conway from the 60’s. His law states that the structure of a computer system reflects the social
structure of the company that made it. While something of a joke, it does have some truth to it.
70. QA
UX / Design
Engineers
DBAs
Front End Service
Internal Tools Services
Order Management Service
THIRDCHANNEL 70
Slide of different groups of people (Designers, Front-End Engineers, Back-end engineers, DBAs, Dev Ops, QA) (color coded)
vs
image of different service teams with different color coded people in them (e.g. front end team with a couple designers and no DBAs; order-management
system with 2 DBAs and no designers)
71. Save Money!
!
Probably the biggest advantage of all of this is that in the end, it should save you time, headaches and money
!
72. Save Money
THIRDCHANNEL
Fewer Resources
&
More Efficient Developers
72
If any of you perked up or are skeptical, I don’t blame you.
Mentioned this to a coworker, and he said “All I see is that you want to pay Amazon a bunch more money for these additional machines”
73. Borrowed this slide from Martin Fowler’s website
!
As demand on the application grows, I can scale just the components that are needed, rather than needing to replicate the whole monolith as demand
grows
74. In the beginning, this may not seem like a huge advantage.
!
However, consider that as your application becomes ever larger and more complex… more resources are going to be needed to power the entire thing.
!
Which results in more machines and resources that may just be there to patch over the the small bounded context of your application which is truly
demanding the attention.
If I have 6 x demand per usual on the billing system only, I argue that it should cheaper to add 6 small billing system nodes than to have to deploy our
monolith 6 times across more expensive machines
79. Use that money to buy developers
beer
developers love beer
80. There are certainly some downsides of the micro service approach, but we’ll get into that later.
!
Generally though, I hope you agree that SOA and Microservices do a decent job of fighting the Monolith…
81. … but we can do even better. Squeeze out even more power from our resources.
82. Questions?
• 1. Microservices are the natural enemy of Monoliths
• 2. Small Code is Fast Code
• 3. Save Money
THIRDCHANNEL
82
83. CAP Theorem
Next, I want to diver a little and discuss something called the CAP Theorem
85. Cap Theorem
• (C)onsistency
• (A)vailability
• (P)artition Tolerance
!
• Pick 2
THIRDCHANNEL
85
And the CAP Theorem says that in a distributed application, your system can only fulfill 2 of those attributes
86. Cap Theorem
• (C)onsistency
• (A)vailability
• (P)artition Tolerance
!
• Pick 2
• Theorem From Paper Which Proved ‘Brewer’s Conjecture’
THIRDCHANNEL
86
87. Originally called Brewer’s Conjecture
In 2012, this paper contained a formal proof of the Conjecture and it graduated to full-on theorem.
!
88. Cap Theorem
• (C)onsistency
• (A)vailability
• (P)artition Tolerance
!
• Pick 2
• Theorem From Paper Which Proved ‘Brewer’s Conjecture’
• Not Fixed / CAP Choices Can be at Service Level
THIRDCHANNEL
88
91. Cap Theorem
• (C)onsistency
• (A)vailability
• (P)artition Tolerance
!
• Pick 2
• Theorem From Paper Which Proved ‘Brewer’s Conjecture’
• Not Fixed / CAP Choices Can be at Service Level
• Origin of Eventual Consistency
THIRDCHANNEL
91
A little bit of trivia -> this paper also introduces the term the term “Eventual Consistency” originated
92. Eventual Consistency
• High Consistent System: After Update, all components see
change
• Eventually Consistent System: After Update, eventually all
components will see change
THIRDCHANNEL
92
… as it propagates throughout the system.
And that’s ok, for most things.
Again, for anything dealing with Money, you’re going to want a highly consistent system.
93. Architecture Choice is
More Important Than Any
Framework
Now, knowing all of that, I reiterate:
Architecture choice…
94. If We accept that Microservices are
Good… how do we build each Service?
How can we squeeze even more power out of our applications? How can we further increase the maintenance advantage of microservices? How can we
further reduce our resource costs?
95. Reactive Microservices
are the ideal Web
Architecture
And so I believe that the ideal architecture for the web is one based on Reactive Applications built on distributed microservices -> not merely SOA.
A distributed Microservice architecture, where each service follows the Reactive approach
96. Going Reactive
But I’ve been stalling… So, when I say ‘Reactive’, what exactly do I mean?
101. Asynchronous Message Passing
Essentially, a Reactive system should be built around the concept of Asynchronous Message Passing.
Take advantage of the asynchronous features of your language or framework, and…
102. -Communication within the system should be done via done via asynchronous immutable events, rather than long procedural code.
-This naturally promotes highly decoupled code. Sender and recipient can be constructed without having to know - or care - about implementation details
of the others.
- I think this is a very important point… and is perhaps the most important facet of Reactive programming as the others may come naturally from adopting
this single step
104. THIRDCHANNEL 104
Suppose we had an E-commerce app which included a service which created and processed orders.
In this version, we use several additional service collaborators to do things like verifying that we have inventory, charge the user, and send emails if
successful or not.
Each of those service calls could take a while (checking inventory, sending email, money), which blocks the thread while we wait for each service call. This
slows down the request not only for the end user but for any rampaging hordes trying to access our app
106. THIRDCHANNEL 106
Here’s that same method. Where did the rest of the code go?
First, note the ‘notify’ with a String-based event
107. THIRDCHANNEL 107
On order:created, we execute the first services job
Then we check the inventory for holding, and broadcast a new event based on those results
108. THIRDCHANNEL 108
! -Now, some of might be saying, “But Steve, that code is spread across 3 different slides!”. While, true, which of these would you rather use? Which version
The moneyService will bill the client if the inventory is good,
While the email service will respond either way.
! -(Imagine having to mock all these services as collaborators, versus simply creating events)
do you think is more decoupled? Which would be easier to test?
109. 4 Reactive Principles
• 1. Event-Driven
• 2. Scalable
THIRDCHANNEL
109
Principle 2. A Reactive Application must be scalable
110. -The system should be able to efficiently grow based on the demand placed on it.
Should be able to replicate easily on or across multiple nodes.
!
Dynamic scaling is an optimal use of resources: can scale up quickly when needed, but can scale down when not
needed (save $)
!
111. Application Topology will Change
As we build, we may not know what the application topology will be at the start… and it may change in the future. Design your systems such that they:
<next>
113. -if one thread or process is blocking access to a service or another resource, than other threads, connections, etc will have to wait. This reduces the CAP
availability, will require more resources (e.g. more machines), and will anger the user if they notice the slowdown.
-horrible contention will have a direct monetary cost as you scramble to scale your resources and keep the end user happy
-this will start to come as a natural emergence of adopting Asynchronous message passing
114. 2. Maximize Locality of
Reference
Include -> part 1. here, build up a list
Maximize locality of reference.
This is a very complicated topic…
115. So much so that I couldn’t think of a snappy image for it.
! -If data is accessed frequently, it’s a good candidate for caching (Temporal)
-Keep related data close together (Spatial). Minimum number of joins to build a particular record
!-
This takes on a different, sinister, twist when working with Microservices, which I’ll get into in a bit
117. Embrace Failure
In fact, *embrace* that catastrophic failures will most assuredly occur.
118. Have the mindset that at any given moment, your code is going to break. Think to yourself: How coupled is my code? How dependent on other services,
domain objects, third party services, etc is my application?
-How many of your systems are held together by metaphorical duct tape?
What happens if any one of those go down?
The worst thing you can do is know that catastrophe is coming or how it *could* come and to do nothing about it.
119. -A Reactive application is resilient to failure. If one service node breaks down, the others should be able to take up the slack. If one feature goes down, the
others should still operate.
-Your system should be able to suffer damage and still operate.
-For example, in the ecomm example, if the order placement feature goes down.. while your team is scrambling to fix, the end user should still be able to
browse the products and add items to the cart.
-They should just see a message that says “Sorry, order placement will be right back”…
-or better yet, take the order, send a note to the customer, and process the orders later once the system is back online
120. Independent Things Fail
Independently
Your resilient mantra should be “Independent things fail independently”
121. Occurs naturally with Async and
Microservices
Design your systems and services to be as loosely coupled as possible.
Using Async messages and microservices helps this behavior to arise naturally
123. Your application, in general, should respond to user interaction as quickly as possible. Thus, each service should handle events quickly.
!
A more ‘responsive’ application is a pleasing experience to your end user. The faster your application responds to their input, the less time they sit staring
at your app, and the happier they’ll be.
!
TODO: Add Amazon delay -> cost
Several years ago, an engineer with Amazon named Greg Linden revealed that the company ran experiment where they intentionally slowed down site
performance
- 100ms delay resulted in 1 percent drop in sales.
!
125. The 4 rules of Reactive Applications are…
-Sorry, I watched Fight Club a week or so ago.
As a result, I’ve got a bit of an anti consumerist streak going.
… he says while giving his presentation on a Mac laptop
126. 1. NEVER BLOCK
!
2. SHARE NO STATE
!
3. INDEPENDENT THINGS
FAIL INDEPENDENTLY
!
4. BE FAST
128. Rather, Reactive is a mindset or a state of being. It’s a goal that you need to orient your thinking around when
you are designing or architecting your individual service nodes and your distributed architecture
129. The people at Typesafe wrote up this thinking into something they call the ‘Reactive Manifesto’.
After this talk, if you like what I’m saying, feel free to go and sign it.
130. “An Application must be Reactive from top to
Bottom”
- The Reactive Manifesto
THIRDCHANNEL 130
131. So, going back to the original e-commerce example…
- how to go reactive?
132. First of course, is to break up our application into individual components. We could build an API to communicate
between services via synchronous HTTP…
134. Route State-less Messages
Asynchronously
Each service should send and respond via the message broker by passing messages asynchronously. (rule #1)
Each message should be entirely stateless (rule #2).
135. - A Reactive system will emerge from Reactive services.
- Once you reach the point where messages are asynchronously bouncing around your system, you’re going to
sit back and just whistle. Unless you’re me. I can’t whistle.
136. Reactive Questions?
• Reactive Is a Mindset
!
• 4 Rules
!
• Reactive Services Emerge into a Reactive Distributed App
THIRDCHANNEL
136
138. 138
THIRDCHANNEL
Development
• Compose Services From libraries
! -an organization will tend to standardize the deployments and internals of new services. This is generally a good thing, but can lead to a great amount of
by nature, working with micro services have an amazing amount of code reuse.
code reuse and boilerplate
139. THIRDCHANNEL 139
Slide of legos?
- Thus, extract the common code into sets of shared, tested, libraries
- Compose every service out of these shared libraries, so that when working on each service you only have to reason about the custom code
140. Development
• Compose Services From libraries
• Architect / Design Team
THIRDCHANNEL
140
141. As mentioned earlier, need an architect to keep everyone on task and following the Reactive microservice
approach.
142. This can be an authoritative committee as well, if that’s too much power in one person’s hands
But keep in mind that everyone in that committee is *going* to have an opinion
143. Development
• Compose Services From libraries
• Architect / Design Team
• Empower your Teams / Make them Responsible
THIRDCHANNEL
143
145. Development
• Compose Services From libraries
• Architect / Design Team
• Empower your Teams / Make them Responsible
• Embrace Eventual Consistency
THIRDCHANNEL
145
146. Embrace Eventual Consistency
The concept that when a change is made to an object within the distributed system, that each service or database may not be consistent with that change,
but they eventually will be. This can be a difficult thing for people to accept, but for most objects I argue that’s OK.
! -Amazon misses an order
147. Development
• Compose Services From libraries
• Architect / Design Team
• Empower your Teams / Make them Responsible
• Embrace Eventual Consistency
• Be worried about Reference Locality
THIRDCHANNEL
147
148. Seriously, be concerned about
Locality of Reference
Each service should be an authority on some section of your data
In general, other services should query the authoritative server when necessary (Thus maintaining spatial locality)
- However, each separate service will need to be aware of the domain objects. Each Service will have a different understanding - or ‘projection’ - into the
particular Domain
149. In an ideal environment, each system would be completely separate.
-However, there will always be some conceptual overlap. For example, let’s say we have a system where <describe system>.
-Red lines are anchors between data localities
- Here, users’ uuid is a shared natural key which acts as each services’ anchor to understanding the concept of a user. In our main user service
understands a plethora of personal information
- Our order history system also understands the user, but simply maintains the order history joined with the user id
150. Same chart from before, but another service, email. This service also conceptualizes the user, but with a different subset of information. Namely, the email
address.
- Email address is stored in the user information service, but is *also* used extensively by the email service. Which one should be the authoritative
source? The email service uses it more (and thus has higher Temporal locality), but email is a key piece of information which should be managed by the
user auth system.
- Tough Choice
- One Compromise is to (unfortunately) synchronize the email address across multiple services
- Or, communication service has no concept of User’s email address, but simply blindly sends emails out. The email addresses involved must be placed
into each message received by the Communication service
151. Practical Development
with Groovy
The Groovy / Grails / Spring / general JVM world is filled with very interesting libraries and tools. It’s an exciting time to be building these scalable,
distributed applications.
152. THIRDCHANNEL 152
Akka
- I’m not smart enough to understand Actors
Actors -> relatively small implementation. Each receives messages in their ‘mailbox’ or message queue.
Walled off from you in terms of configuration and deployment: you access actors via a proxy. This means that actors can be easily distributed across
machines for dramatic increase in computational power.
154. Reactor is my favorite. It’s the easiest to use with the most straightforward applicability.
A Reactor instance is a wrapper around one of several different Dispatcher types (e.g. a standard Event Loop, an LMAX Disrupter Ring Buffer).
A reactor acts like a central dispatcher within your service node
155. The folks at Netflix have been kind enough to give us ReactiveX, a suite of various reactive tools for a variety of (primarily JVM) languages.
!
156. <sample rxGroovy Code>
The rxGroovy (or rxJava) libraries give you a tool called an Observable Sequence with which it’s possible to assemble reactive applications.
!
We can do simple asynchronous list processing or transformations…
157. …
or a publish subscribe approach
I believe it’s an extraordinarily useful tool for working with Groovy sequences in an asynchronous fashion.
159. ! In my opinion, the two most useful currently are the Promise support and Asynchronous Request Handling
And, with Grails specifically, we have the built in Async Support
163. Remember to verify that your servlet version set to 3.0 in BuildConfig.groovy
164. But Be Careful
It’s not all sunshine and roses (cupcakes and snowflakes?), however.
There are areas of difficulty with Reactive microservices, both in deciding whether or not to build them and the practical development.
165. Caveats
• Not The Right Fit For Everyone
THIRDCHANNEL
165
166. THIRDCHANNEL 166
-A Word press blog that your parents are building, a local restaurant site, or any general informational page…
-Probably not a good candidate for this approach
- Now, for your startup… you may be saying “I’m not yet a huge internet giant. This seems hard”.
- How much more difficult will it be when you eventually realize that a distributed approach would be a huge help?
-
167. Caveats
• Not The Right Fit For Everyone
• Initial Investment is LARGE
THIRDCHANNEL
167
168. Caveats
• Not The Right Fit For Everyone
• Initial Investment is LARGE
• Initially Very Difficult
THIRDCHANNEL
168
This approach is an investment…
169. THIRDCHANNEL 169
An investment of both time and money. At first, a micro service architecture may look crazy, particularly perhaps, to your bosses. It’ll pay off dividends in
the end, but that initial investment can be cost prohibitive.
170. Caveats
• Not The Right Fit For Everyone
• Initial Investment is LARGE
• Initially Very Difficult
• Make sure Everyone’s on Board
THIRDCHANNEL
170
171. ! If someone on your team doesn’t agree or doesn’t Understand the microservices approach, it’s possible that they may create faulty services
172. Caveats
• Not The Right Fit For Everyone
• Initial Investment is LARGE
• Initially Very Difficult
• Make sure Everyone’s on Board
• Can Lead to Team Animosity
THIRDCHANNEL
172
173. Because teams are responsible for a service, it can lead to an us-vs-them mentality. If a service is broken, the teams relying on that service can began to
fall back to a ‘Well I can’t do any work because the User Management service is down”.
Encourage teams to cooperate. Cycle team members to other groups periodically.
174. Caveats
• Not The Right Fit For Everyone
• Initial Investment is LARGE
• Initially Very Difficult
• Make sure Everyone’s on Board
• Can Lead to Team Animosity
• Conway’s Law
THIRDCHANNEL
174
Be ever watchful for Conway’s Law. Ensure that your teams are working together when designing their services… otherwise you’ll find that certain services
are tailor-made to communicate more efficiently and directly with others.
175. Case Studies
In the end, though, it’s all worth it.
!
Some of the largest companies out there are demonstrating to the world that this approach is ideal for the web.
176. First up: our good friends Netflix
!
-make heavy use of AWS
-replicate bundles of services as demand dictates
-Netflix is big on resiliency. In order to test their resiliency, they use a custom tool called ‘Chaos Monkey’
177. Every weekday between 9am and 5pm (a.k.a. “Work Hours), Netflix unleashes this little adorable little guy into
their infrastructure, where he goes to work randomly destroying various services.
178. And the Chaos Monkey was just the first. They have a whole army of monkeys that do things like:
- simulating high latency and service degradation
- clean up unused resources
- monitor health checks to detect and alert for unhealthy instances
179. These services need to prove their strength and stand up to the simian army.
Or rather, this allows Netflix to find weaknesses and bugs in their services
181. Netflix <3’s Groovy
- Groovy is used extensively throughout Netflix’s services
- Whatever insane amount of the world’s web traffic goes through their services? That’s touching Groovy code
- the next time someone tells you that Groovy’s too young, or we need Java, or some other excuse, just point to Netflix
183. They had one of the largest, most monolithic Rails deployments in the world.
-Engineers needed to pull in Global Experts to get anything done on the codebase
-Spent more time on “Archeological Digs” or “Whale Hunting expeditions” to track down bugs or learn how
things worked than on developing new features
184. Turning point came during 2010 World Cup. Flurry of tweets brought twitter to its knees.
Service was unavailable, engineers worked through the night
Debated putting a vuvuzella sound effect here.
187. They shattered their monolithic application into multiple individual applications..
The size of the circles represent the number of deployment nodes of that particular application service
-I know I just spoke about Rabbit, but Twitter developed their own tool called Finagle which handles
asynchronous communication between nodes
189. -they switched from the Ruby Virtual Machine to the JVM.
-Embraced Event-based programming from the bottom up
Went with Netty (as opposed to something like NodeJS), which is an NIO technology for the JVM
191. During the 2010 World Cup, Twitter hit a
record of 3283 TPS
During the 2010 World Cup, Twitter reached a record (at the time) of 3283 tweets per second before the service collapsed.
192. Now: average 5700 TPS
Dynamically scale to 143,199 TPS
Now, they average 5700 tweets per second… but their systems are set up so that they can dramatically scale up on demand. The current record is 143,199
tweets per second.
That’s not a hard number… that’s just the most they’ve received. They could theoretically handle more, it just hasn’t happened yet.
193. With 5x - 12x fewer nodes
And they’ve done all of this with 5 to 12 times fewer service nodes.
!
Not bad, yeah?
194. //That’s kind of mind blowing, right? Not Bad, eh?
!
-> Incidentally, JVM advocates and Rails detractors love to talk about how Twitter moved away from Rails to Java.
And while that’s true that Java would give better performance, the Architecture choice was vastly more important
196. About ThirdChannel
THIRDCHANNEL 196
- I should spend a bit of time explaining my company ThirdChannel. Normally, I might save it, but in order to fully understand the context it’s good to have a
bit of background on us
197. This is a slide from a sales deck, I apologize for the marketing speak
But basically, the problem we’re trying to solve…
<explain 3c>
199. Another sales slide, but this gives a flavor of what our current feature set is(or 2 months ago current, actually), and how it looks on mobile
200. We Need Many Services
… or rather, we have many internal bounded contexts that I feel can be utilized as discrete services
201. (Show slides of services, adding one by one)
First, we have the web interface.
-Contains the Marketing Site, plus the basic structure of the internally facing site.
202. !
We started with gathering observational data (rather than empirical sales data), and this second service is still our most used context (beyond, of course,
the front-end service).
This service is responsible for receiving and providing a query-able interface for the data we gather.
203. To gather all of that data, we use Agents. However, each Customer could have several dozen to several hundred agents, so we need services to both help
our staff with Agent Recruitment, and Agent Management (e.g. which stores they’re currently assigned to).
The checkin server and I believe also the web interface query the agent management service to determine which stores an agent is both shown and
allowed to provide data for.
204. And we do pay those agents pretty well… so we need a service to track payments per some payment schedule. Each Customer may pay agents differently,
so that logic needs to be handled.
Every two weeks
205. And all of that, so far, is mostly just for Agents!
!
Notification Service: sends emails and tracks internal messages within the app.
207. as well as a bunch of additional services for aggregating data into different query able formats
208. And we’re still going
-And we still have more to do
- This is just what we’ve managed to work towards this year. Is each one perfect? Absolutely not. We’re iterating on each one of those services - plus a few
other very minor ones - constantly…. and rapidly, without impacting other services or areas of the business
- if we go back one slide, we’re mostly working on the analytics services right now … in addition to revamping our main front end - and we’re not impacting
the large agent management team we have at all
209. Our Lessons Learned
During this process there have certainly been stumbling blocks, though
212. Agree on a Messaging format
! (Image of strife) Our discussions weren’t actually like that. But, you know. not far off.
What data type are you going to use xml? json? How about format? Something already established, like HAL?
How much data should be sent? Should every service be able to customize the response it wants? What about when broadcasting general informational
updates
214. Lessons Learned
• #1 Agree on a Messaging Format
• #2 Build Communication Libraries
THIRDCHANNEL
214
The very second thing that should be built is a shared library (or libraries) for facilitating communications that utilizes the pre-mentioned messaging
formats
215. Lessons Learned
• #1 Agree on a Messaging Format
• #2 Build Communication Libraries
• Maintain API Documentation
THIRDCHANNEL
215
Next, make sure that - for each service - you maintain proper API documentation
216. This documentation about each service should cover it’s externally facing concerns.
!
Describe which events it emits and what sort of data it sends out during each event.
Describe how to communicate directly with the service, if at all. Do you talk to it directly via HTTP? Does the service respond to RPC calls over the
message queue? What sort of input does it expect?
217. Lessons Learned
• #1 Agree on a Messaging Format
• #2 Build Communication Libraries
• Maintain API Documentation
• Remember Conway’s Law
THIRDCHANNEL
217
Keep communication up between service teams… ESPECIALLY when you’re just starting out.
!
When these communication patterns are still in the early stages, it’s very important that everyone in your entire team understand how it will work
! I’d recommend a meeting once or twice a week for service team leads to meet and discuss things like “So I’m planning on emitting this event. Any
thoughts one data you all might need?”, or “Hey, can you update the shopping cart service to also send this data along with event Y?”
218. Lessons Learned
• #1 Agree on a Messaging Format
• #2 Build Communication Libraries
• Maintain API Documentation
• Remember Conway’s Law
• Always Think of Data Locality
THIRDCHANNEL
218
219.
220. Lessons Learned
• #1 Agree on a Messaging Format
• #2 Build Communication Libraries
• Maintain API Documentation
• Remember Conway’s Law
• Always Think of Data Locality
• Consider Capturing & Logging All Events / Auditing
THIRDCHANNEL
220
228. Any Questions?:
• 1. Monolithic Apps will Ruin you
• 2. Service Oriented Architecture and Microservices
• 3. Reactive Applications
• 4. Practical Development (Caveats)
• 5. Case Studies (including 3C)
THIRDCHANNEL
228
Steve Pember
CTO, ThirdChannel
@svpember
steve@thirdchannel.com
In conclusion, this is what I attempted to go over today.
Any questions?
229. Image Credits
Complexity (pipes): http://www.flickr.com/photos/bhophoto/384574407/
Simple Pipeline: http://tierracos.com/our-companies/tierra-pipeline/
Highway: http://farnorthdallas.advocatemag.com/wp-content/uploads/2013/04/882349_500402383328407_539732406_o.jpg
Telephone Exchange Operator: http://fineartamerica.com/featured/telephone-exchange-1920s-granger.html
People in Queue: http://www.guardian.co.uk/money/2010/mar/23/dole-queue-jobseekers-online
Cookie Monster: http://muppet.wikia.com/wiki/Cookie_Monster_Through_the_Years
Too Many Cooks: http://www.ecommercesystems.com/featured-articles/cooks-kitchen-driving-ecommerce-business/
Resuscitate: http://www.dailymail.co.uk/health/article-2034160/Do-resuscitate-Theyre-fateful-words-meaning-doctors-wont-try-save-you-collapse-hospital.
html
Twitter Logo & app chart: https://blog.twitter.com/engineering
Modern Server Farm: http://bookriot.com/2013/03/26/book-less-libraries-and-other-contemporary-realities/
Grey World: http://upload.wikimedia.org/wikipedia/commons/d/d0/BlankMap-World-1ce.png
Monolith: http://filmessaysandarticles.wordpress.com/
Star Trek: http://www.gifbin.com/984064
Reactive Manifesto: http://www.reactivemanifesto.org/
Cheetah: http://www.livescience.com/21944-usain-bolt-vs-cheetah-animal-olympics.html
Buzzword Bingo: http://www.amsterdamadblog.com/columns/buzzword-bingo/
Businessman meditating: http://www.huffingtonpost.co.uk/2013/07/09/meditation-successful-businessmen_n_3567694.html
Chaos Monkey: http://luckyrobot.com/netflix-chaos-monkey-keeps-movies-streaming/
Darth Vader: http://www.businessinsider.com/hillary-clinton-darth-vader-poll-2014-7
Turtles: http://people.wcsu.edu/pinout/herpetology/tcarolinei/29366343.EasternBoxTurtle2.jpg,
http://www.huffingtonpost.com/2013/04/26/24-tiny-turtles-who-need-a-reality-check_n_3134793.html,
http://www.ecology.com/2012/05/23/world-turtle-day/
“Maintenance Rocks”: http://www.prlog.org/12205104-grace-hill-inc-declares-september-maintenance-appreciation-month.html
NFL Ref: http://www.mprnews.org/story/2012/09/03/news/nfl-referees
“Say No to Sharing”: http://www.cultofandroid.com/15519/sprint-starts-say-no-to-sharing-campaign-against-shared-data-plans/
“Dominoes” https://www.flickr.com/photos/louish/5611657857/sizes/l/in/photostream/
“First Day on the Internet Kid” http://knowyourmeme.com/photos/239112-first-day-on-the-internet-kid
“Tortoise and the Hare”: http://www.theguardian.com/sustainable-business/social-enterprise-blog/2014/feb/10/week
“Star Trek”: http://keyepisodes.blogspot.com/2013/10/star-trek-next-generation.html
“Darryl Issa” http://nypost.com/2014/03/05/shouting-match-erupts-during-house-hearing-on-irs-scandal/
“Fight Club” http://pyxurz.blogspot.com/2012/05/fight-club-page-4-of-7.html
“Woman looking at phone” http://remedybail.com/blog/page/4
“Guy with metal detector” http://beachurbanity.blogspot.com/2010/04/beach-metal-detector.html
“Happy dog” http://sydneespetgrooming.com/blog/
“Trekking in the desert”: http://www.wildmorocco.com/
“morpheus”: http://www.desktopexchange.net/movie-pictures/matrix-wallpapers/
“Monoliths and Microservices” http://martinfowler.com/articles/microservices.html#CharacteristicsOfAMicroserviceArchitecture
“Calvin fighting” : http://commonsenseatheism.com/?p=2214
“Sample Restaurant” : http://www.letseat.at/
“Solar panels”: http://prepare-and-protect.net/2014/02/solar-panels/