At Wunderlist, they embrace polyglot microservices to reduce deployment fear and increase change ability. They emphasize small, independent, self-documenting services using various programming languages. Over time, they have expanded from a few large monoliths to many smaller services across languages, which has improved flexibility without increasing complexity through clear interfaces. Their goal is to continuously improve systems through experience with challenging architectures.
Things will Change - Usenix Keynote UCMS'14Erica Windisch
From servers and containers, to services and things. Building an Internet of Things of the clouds and infrastructure we're building today. Maps the future of configuration management and systems artifact management.
Decomposing applications for deployability and scalability(SpringSource webinar)Chris Richardson
Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers.
In this talk we describe the limitations of a monolithic architecture. You will learn how to use the scale cube to decompose your application into a set of narrowly focused, independently deployable back-end services and an HTML 5 client. We will also discuss the role of technologies such as Spring and AMQP brokers. You will learn how a modern PaaS such as Cloud Foundry simplifies the development and deployment of this style of application.
Microservices have been around since a few years, and many organizations are starting to benefit from these autonomous, independently deployable and easy maintainable small blocks of code. However, if you examine some of the popular definitions of microservices, we are still building a single application as a suite of small services.
During this talk Sander Hoogendoorn will explain and demonstrate how front-end development can also benefit from building it in small autonomous, independently deployable blocks of code, instead of implementing a single monolithic web application. Of course, Sander will use many code examples in Java, Angular and Typescript (and probably some live coding) to illustrate even better how to build micro-applications similar to your microservices.
Things will Change - Usenix Keynote UCMS'14Erica Windisch
From servers and containers, to services and things. Building an Internet of Things of the clouds and infrastructure we're building today. Maps the future of configuration management and systems artifact management.
Decomposing applications for deployability and scalability(SpringSource webinar)Chris Richardson
Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers.
In this talk we describe the limitations of a monolithic architecture. You will learn how to use the scale cube to decompose your application into a set of narrowly focused, independently deployable back-end services and an HTML 5 client. We will also discuss the role of technologies such as Spring and AMQP brokers. You will learn how a modern PaaS such as Cloud Foundry simplifies the development and deployment of this style of application.
Microservices have been around since a few years, and many organizations are starting to benefit from these autonomous, independently deployable and easy maintainable small blocks of code. However, if you examine some of the popular definitions of microservices, we are still building a single application as a suite of small services.
During this talk Sander Hoogendoorn will explain and demonstrate how front-end development can also benefit from building it in small autonomous, independently deployable blocks of code, instead of implementing a single monolithic web application. Of course, Sander will use many code examples in Java, Angular and Typescript (and probably some live coding) to illustrate even better how to build micro-applications similar to your microservices.
Architecting for speed: How agile innovators accelerate growth through micros...Jesper Nordström
In a world where software has become the key differentiator, enterprises are forced to transform the way they build, ship and run software in order to stay in the game. Competitive pressure requires applications to be rapidly and continuously upgraded with nonstop availability, and companies that lack the capacity to experiment, innovate and get new features out quickly, will be at disadvantage. This is driving many IT organisations to adopt the software design model known as microservices architecture, which quickly is gaining traction as a new way to think about structuring applications, and is changing the fundamentals of enterprise application management.
Architecting for speed - how agile innovators accelerate growth through micro...3gamma
In a world where software has become the key differentiator, enterprises are forced to transform the way they build, ship and run software in order to stay in the game. Competitive pressure requires applications to be rapidly and continuously upgraded with nonstop availability, and companies that lack the capacity to experiment, innovate and get new features out quickly, will be at disadvantage.
This is driving many IT organisations to adopt the software design model known as microservices architecture, which quickly is gaining traction as a new way to think about structuring applications, and is changing the fundamentals of enterprise application management.
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...Ambassador Labs
Ben Christensen of Facebook, Netflix, and author of Hystrix.
In pursuit of ease and obedience to the DRY ("don't repeat yourself") axiom, it is common to build a distributed monolith instead of the intended decoupled microservice architecture. This talk will explore the common pitfalls, the pain they cause, and approaches to connecting microservice permitting the promised separation of concerns that allows varied architectures, platforms, languages, timelines, and incremental rewrites of a microservice system.
Full video here: http://www.microservices.com/ben-christensen-do-not-build-a-distributed-monolith
Microservices pattern language (microxchg microxchg2016)Chris Richardson
My talk from http://microxchg.io/2016/index.html.
Here is the video - https://www.youtube.com/watch?v=1mcVQhbkA2U
When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
CHRIS RICHARDSON FOUNDER, EVENTUATE
When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs. A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
A pattern language for microservices (melbourne)Chris Richardson
When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
#JaxLondon keynote: Developing applications with a microservice architectureChris Richardson
The micro-service architecture, which structures an application as a set of small, narrowly focused, independently deployable services, is becoming an increasingly popular way to build applications. This approach avoids many of the problems of a monolithic architecture. It simplifies deployment and let’s you create highly scalable and available applications. In this keynote we describe the micro-service architecture and how to use it to build complex applications. You will learn how techniques such as Command Query Responsibility Segregation (CQRS) and Event Sourcing address the key challenges of developing applications with this architecture. We will also cover some of the various frameworks such as Spring Boot that you can use to implement micro-services.
Microservices: Why and When? - Alon Fliess, CodeValue - Cloud Native Day Tel ...Cloud Native Day Tel Aviv
Do more with less, the pain of the modern architect. High cohesion & low coupling, high availability & scale, ease of DevOps. Our systems need to support all these quality attributes, while providing more functionality with less resources. We need to be agile, we need to embrace changes, we need to have a better way! Micro-Service-Architecture (MSA) promises to bring cure to the architect's pains, but does it really deliver? This lecture presents the essence of MSA, how does it answer main concerns of modern distributed systems, how to get started, how to migrate current solutions to MSA by adopting an evolution migration path. What to be careful about and the signs that we are on the right track. We will talk about SA evolution, the CAP theorem and eventually consistency, MSA principles, hosting. containers, versioning, orchestrators & decoupling business processes. By the end of this lecture the participant will have a better understanding of why, when and how to embrace MSA.
It's easy to say... Microservices! Reality is we need to learn and apply concepts coming from many disciplines like SOA, EDA and DDD just to name a few! Mix them with some ALM and technical processes around Packaging and Deploying... and maybe then you get a true Microservices solution.
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.
Moving "Something Simple" To The Cloud - What It Really TakesCloverDX
On-Demand Webinar slides
We'll examine the difference between deploying on-premise, the "VM way" and the fully-cloud way. Take a behind-the-scenes look at a real-life case, where a requirement from several business units triggered a hasty implementation at first, then raised some fundamental questions, and eventually lead to a cascade of decisions and an AWS cloud solution that works (but no one anticipated).
Watch the webinar here: https://www.cloverdx.com/gc/lp/webinar/moving-something-simple-to-cloud-from-on-premise
This talk is an appeal to server-side JavaScript developers to make
use of this time of change - Node.js is going to become the primary
server-side platform for most developers. We can move forward from
the old way of building web apps as large inter-locking co-dependent
code bases.
The Node.js module system has shown us the way. It's the first
step. Now, we need to use the beauty of Node modules to help us build
robust, scalable apps.
This approach is called the Micro-Services Architecture. It's more
than just having some services with HTTP end-points. It's about taking
this to the extreme. Everything is a service, and no service is larger
than 100 lines of code.
We've been using this approach for most of our projects for the last 18
months and it works really well. We get to drop loads of
project management ceremony. There will be some customer war stories.
Enterprise software teams are starting to understand and embrace the
power of Node.js. They face a serious challenge: integrating Node.js
into the legacy systems they maintain, and migrating these system over
time into Node.js architectures. This talk is a pathfinder for those
facing this task. As a community we must proactively engage with the
Java and .Net communities, and create a deeper understanding of the
"Node.js Way".
Bridging the Digital Gap Brad Spiegel Macon, GA Initiative.pptxBrad Spiegel Macon GA
Brad Spiegel Macon GA’s journey exemplifies the profound impact that one individual can have on their community. Through his unwavering dedication to digital inclusion, he’s not only bridging the gap in Macon but also setting an example for others to follow.
Architecting for speed: How agile innovators accelerate growth through micros...Jesper Nordström
In a world where software has become the key differentiator, enterprises are forced to transform the way they build, ship and run software in order to stay in the game. Competitive pressure requires applications to be rapidly and continuously upgraded with nonstop availability, and companies that lack the capacity to experiment, innovate and get new features out quickly, will be at disadvantage. This is driving many IT organisations to adopt the software design model known as microservices architecture, which quickly is gaining traction as a new way to think about structuring applications, and is changing the fundamentals of enterprise application management.
Architecting for speed - how agile innovators accelerate growth through micro...3gamma
In a world where software has become the key differentiator, enterprises are forced to transform the way they build, ship and run software in order to stay in the game. Competitive pressure requires applications to be rapidly and continuously upgraded with nonstop availability, and companies that lack the capacity to experiment, innovate and get new features out quickly, will be at disadvantage.
This is driving many IT organisations to adopt the software design model known as microservices architecture, which quickly is gaining traction as a new way to think about structuring applications, and is changing the fundamentals of enterprise application management.
Microservices Practitioner Summit Jan '15 - Don't Build a Distributed Monolit...Ambassador Labs
Ben Christensen of Facebook, Netflix, and author of Hystrix.
In pursuit of ease and obedience to the DRY ("don't repeat yourself") axiom, it is common to build a distributed monolith instead of the intended decoupled microservice architecture. This talk will explore the common pitfalls, the pain they cause, and approaches to connecting microservice permitting the promised separation of concerns that allows varied architectures, platforms, languages, timelines, and incremental rewrites of a microservice system.
Full video here: http://www.microservices.com/ben-christensen-do-not-build-a-distributed-monolith
Microservices pattern language (microxchg microxchg2016)Chris Richardson
My talk from http://microxchg.io/2016/index.html.
Here is the video - https://www.youtube.com/watch?v=1mcVQhbkA2U
When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
CHRIS RICHARDSON FOUNDER, EVENTUATE
When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs. A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
A pattern language for microservices (melbourne)Chris Richardson
When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
#JaxLondon keynote: Developing applications with a microservice architectureChris Richardson
The micro-service architecture, which structures an application as a set of small, narrowly focused, independently deployable services, is becoming an increasingly popular way to build applications. This approach avoids many of the problems of a monolithic architecture. It simplifies deployment and let’s you create highly scalable and available applications. In this keynote we describe the micro-service architecture and how to use it to build complex applications. You will learn how techniques such as Command Query Responsibility Segregation (CQRS) and Event Sourcing address the key challenges of developing applications with this architecture. We will also cover some of the various frameworks such as Spring Boot that you can use to implement micro-services.
Microservices: Why and When? - Alon Fliess, CodeValue - Cloud Native Day Tel ...Cloud Native Day Tel Aviv
Do more with less, the pain of the modern architect. High cohesion & low coupling, high availability & scale, ease of DevOps. Our systems need to support all these quality attributes, while providing more functionality with less resources. We need to be agile, we need to embrace changes, we need to have a better way! Micro-Service-Architecture (MSA) promises to bring cure to the architect's pains, but does it really deliver? This lecture presents the essence of MSA, how does it answer main concerns of modern distributed systems, how to get started, how to migrate current solutions to MSA by adopting an evolution migration path. What to be careful about and the signs that we are on the right track. We will talk about SA evolution, the CAP theorem and eventually consistency, MSA principles, hosting. containers, versioning, orchestrators & decoupling business processes. By the end of this lecture the participant will have a better understanding of why, when and how to embrace MSA.
It's easy to say... Microservices! Reality is we need to learn and apply concepts coming from many disciplines like SOA, EDA and DDD just to name a few! Mix them with some ALM and technical processes around Packaging and Deploying... and maybe then you get a true Microservices solution.
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.
Moving "Something Simple" To The Cloud - What It Really TakesCloverDX
On-Demand Webinar slides
We'll examine the difference between deploying on-premise, the "VM way" and the fully-cloud way. Take a behind-the-scenes look at a real-life case, where a requirement from several business units triggered a hasty implementation at first, then raised some fundamental questions, and eventually lead to a cascade of decisions and an AWS cloud solution that works (but no one anticipated).
Watch the webinar here: https://www.cloverdx.com/gc/lp/webinar/moving-something-simple-to-cloud-from-on-premise
This talk is an appeal to server-side JavaScript developers to make
use of this time of change - Node.js is going to become the primary
server-side platform for most developers. We can move forward from
the old way of building web apps as large inter-locking co-dependent
code bases.
The Node.js module system has shown us the way. It's the first
step. Now, we need to use the beauty of Node modules to help us build
robust, scalable apps.
This approach is called the Micro-Services Architecture. It's more
than just having some services with HTTP end-points. It's about taking
this to the extreme. Everything is a service, and no service is larger
than 100 lines of code.
We've been using this approach for most of our projects for the last 18
months and it works really well. We get to drop loads of
project management ceremony. There will be some customer war stories.
Enterprise software teams are starting to understand and embrace the
power of Node.js. They face a serious challenge: integrating Node.js
into the legacy systems they maintain, and migrating these system over
time into Node.js architectures. This talk is a pathfinder for those
facing this task. As a community we must proactively engage with the
Java and .Net communities, and create a deeper understanding of the
"Node.js Way".
Similar to Atmosphere Conference 2015: What we've learned from writing dozens of polyglot micro services (20)
Bridging the Digital Gap Brad Spiegel Macon, GA Initiative.pptxBrad Spiegel Macon GA
Brad Spiegel Macon GA’s journey exemplifies the profound impact that one individual can have on their community. Through his unwavering dedication to digital inclusion, he’s not only bridging the gap in Macon but also setting an example for others to follow.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
Italy Agriculture Equipment Market Outlook to 2027harveenkaur52
Agriculture and Animal Care
Ken Research has an expertise in Agriculture and Animal Care sector and offer vast collection of information related to all major aspects such as Agriculture equipment, Crop Protection, Seed, Agriculture Chemical, Fertilizers, Protected Cultivators, Palm Oil, Hybrid Seed, Animal Feed additives and many more.
Our continuous study and findings in agriculture sector provide better insights to companies dealing with related product and services, government and agriculture associations, researchers and students to well understand the present and expected scenario.
Our Animal care category provides solutions on Animal Healthcare and related products and services, including, animal feed additives, vaccination
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
22. Websocket
Wunderlist 3.0
Backend
A simplified diagram of our micro
services at launch last year
*not to scale
HTTP
Business Logic (English) Services
Data Access Logic (German) Services
Databases
Messaging
23. Wunderlist
Backend Now
Nine months later…
*still not to scale
WebsocketHTTP
Business Logic (English) Services
Data Access Logic (German) Services
Databases
Messaging
I’m going to open with a challenging statement. Why do we make it? Because it’s our stand for making software that works.
All sorts of studies show that we’re pretty bad at shipping software. And, one of the reasons why is that the natural progression of software is towards tight coupling. It’s in our nature. We start typing and building. When you’re under deadline or other pressures, you go for expediency. By the time it’s obvious that you need to break things apart, it’s to late.
When things get large and brittle, deployment gets scary. What was easy to ship becomes hard. And, in a strange self-reinforcing way, the more you avoid deployment, the scarier it gets.
Testing is great stuff. It’s the right thing to do. But they can become their own brittle beasts, especially if you keep adding to them and don’t take out the tests that aren’t appropriate anymore. We’ve all seen codebases with large test suites where there are some number of tests that are always failing. That somehow becomes acceptable, even if you know that it shouldn’t be.
In any monolithic system, technology upgrades become expensive and scary. Going from Ruby 1.9 to 2.0, for example. Or versions of Rails.
Smart developers come along, see this, and then build abstractions on top of it all to hide it and move along. This happens a few times and you get design pattern soup. Even if you’re a proponent of design patterns, you know what I mean.
Lots of non-software systems aren’t like this. We can drive around in ancient cars on modern roads, for example. And self-driving cars are going to be using those same roads soon.
Biology gives us an interesting model to work with. Homeostasis is an organism’s ability to self-regulate even in the face of its own self-destructive tendencies. Balance is the key. What software equivalent is there to a cell? That’s what we want.
Small pieces of granular functionality that can work with others. They can be replenished and replaced and the system continues to move on. That’s the whole point of microservices.
So, to fight a slide into bad practices—or maybe as a goad into getting somewhat better, Chad, our CTO, established these simple rules during the building of Wunderlist 3.0 backend. Do it. Deploy it. Go go go.
We use technologies where we can make things so small that tests might even be considered to be optional, certainly after your done developing the code. If we can make services so small that any programmer can read them over coffee, then they can be replaced with something in another language quickly.
We believe that code should document itself. All of us know how easy it is to mentally filter out comments in code. Heck, syntax highlighting makes it trival. If you have to comment simple code to understand it, you’re doing it wrong.
This may be controversial to some, but we believe that if you spend more time in tests to make them work than on the system you’re building, there’s a bigger problem.
We used to have one huge database for everything. Now we have dozens. This means we can change tech from MySQL to Postgres or even to something else for any single service at will with no other services caring. The only thing we lose is foreign key constraints, but we’re ok with that.
We think micro services work best when the requests between them are small. And we like REST. Of course, this leads to lots of tiny requests going back and forth.
Inside a data center, making lots of HTTP requests over a fast network has impact, but not enough to care about. Over the open network, however, connection setup latencies really add up and slow down a system that relies on small packets.
Because of the clients we needed to support, including our web client, needed to be able to use the networking facilities at hand, we turned to HTTP websockets.
Once a client establishes a connection, each request is made as an HTTP request encapsulated inside JSON. This mechanic lets us use the same client and server logic no matter whether we are using straight HTTP or the websocket connection. The addition of the request-id header lets us tie requests and responses together over the asynchronous websocket connection.
Smart of you to ask. Well, it’s still on the way. We should probably roll to it sooner than later and we’ll be happy to.
We’re native on every client: Web, iOS, Mac, Windows 8, Android. And on the back end, we use the tool for the job.
When we launched 3.0 last summer, we had decomposed our single large Rails app into a fleet of small apps—most of the Rails based. We had some other things going on. Scala for the Websocket server. Clojure in our messaging router. We also had mostly Postgres databases, but a few others.
As we’ve progressed and our traffic has scaled up, we’ve replaced many of our Rails business logic services with Scala ones. The performance pick up is massive. We’re also converting much of our data access over to Clojure. Here, we’re taking a step-by-step approach, pairing Rails write servers with Clojure based read servers. MySQL is being phased out.
Does this mean Ruby on Rails is being totally phased out at Wunderlist? Not at all. We use it for production quality prototyping. The first draft of almost everything is in Ruby. Once we’ve sorted out what it should do and we see that Rails isn’t keeping up, we move on.
We’ve been really impressed with both JVM languages and Go. Scala is powerful. Sometimes too much of a kitchen sink. Clojure has been an excellent fit for message distribution and CRUD operations. And Go, while it’s a bit odd in its way, is amazing for some purposes.
Does this mean Ruby on Rails is being totally phased out at Wunderlist? Not at all. Our Haskell service rocks. Elixir and Erlang? Sure.
Finally, we’ve found that our use of multiple languages helps us keep simple interfaces. When you write everything in Ruby, then you use monkey patching and a bunch of other things because you can. Scala to Scala, same story. Ruby to Scala forces simplicity.
Where are we going from here?
Right now, we manage balance in the system manually. We can see in our graphs when something is out of balance and we’ve noticed we follow the same actions. So we’ll code them and make rules so that when pressure shows up in one part of the system, balance can be automatically re-established.
If we are really serious about machines being replaced all the time, then lets use instances that are cheap, but could be shut down. Currently using for workers in an auction based system. Maybe soon rolling to HTTP responders. Inspired by Pintrest’s work on this.
Some parts of our infrastructure are based on Akka and we’re really happy with the way that actors work. In fact, the most robust parts of our system are implemented as actors. What if we made our basic data types actors? We’re really interested in where things like Project Orleans are going with virtual reliable actors. Really, if you get to the core of what an Actor is and what messaging is and how it relates to how we build our systems, you get to a pretty universal truth somewhere down there.
Obviously we have lots of freedom on the server side, but how far can we push it on the client side? How about a client whose components only communicated on a message bus? Or an Android client that used separate Services? What if we broke everything down into small messages passed around via NSOperation on Mac and iOS?
Now that we’ve learned how to run a massively polyglot immutable infrastructure, what happens if we try to take some of those lessons and build up somewhat bigger services? Maybe even a monolith that’s different. Whoever said that micro services were a poor mans implementation of a good Erlang actor system is probably right. Maybe there are other ways to force simplicity that we should look at. Other forcing functions that do what multiple languages do for us now.
Finally, a lesson from XP: If something is hard, do it often and get good at it.