Duration 39:44
16+
Play
Video

RailsConf 2019 - Service Architectures for Mere Mortals by Jamie Gaskins

Jamie Gaskins
Masters of Arts in Christian Apologetics at Trident Technical College
  • Video
  • Table of contents
  • Video
RailsConf 2019
May 2, 2019, Minneapolis, USA
RailsConf 2019
Request Q&A
Video
RailsConf 2019 - Service Architectures for Mere Mortals by Jamie Gaskins
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Add to favorites
1.48 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Jamie Gaskins
Masters of Arts in Christian Apologetics at Trident Technical College

Experienced Digital Broadcast Engineer for the Distance Learning and Broadcast Services Department, at Trident Technical College. Currently serves as their primary support for D2L, YouSeeU, EAB Campus, EAB Navigate, as well as an audio video engineer for Distance Learning productions and support with the post-production editing of digital media. Currently has earned a Bachelor of Science from Liberty University, two Associate of Science and five Certificates from Trident Technical College. As of this January the journey to a Masters of Christian Apologetics will begin.

View the profile

About the talk

RailsConf 2019 -Service Architectures for Mere Mortals by Jamie Gaskins


You may have heard the terms "Microservices" and "Service-Oriented Architecture" in the past, but you've tried to understand them by googling and asking people and that only resulted in either an incomplete picture of how it works or, more likely, a bunch of wildly varied and even conflicting information. Or maybe you do understand them, but getting from your Rails monolith to that structure is a fuzzy path at best.

During this presentation, you will learn the basics of these ideas, the problems they solve, the tradeoffs they impose, and some ways to migrate to them.

Share

Today while we're going be talking about service architectures for mere mortals. Now. I say mere mortals and not think something like me a service architecture for dummies because nobody here either in this room or watching video later is a dummy for not knowing this stuff is very complex. We're all trying to get through a very complicated job or the answer to every question is it depends and so we're going to Italy so it's okay not to know a lot of these things. So we just just recognize that we are all mere mortals in here. So

I think we're going to go over today or what service-oriented architecture is we're going to compare that with our our traditional rails monolithic app to look at some communication patterns between between between these decentralized. To start off with what is service rendered architecture problem is it is there is no single definition. This is a problem, but it's actually there are good and bad things to it. Let's start off with some of the downsides one is that it's hard to Google

and it's not that you won't find any information about it. It's a problem is you're going to find way too much. You're going to find an overwhelming amount of information about service-oriented architecture. But a lot of it probably won't be something that's actionable to you as real developer. It's so hard to figure out like what applies in certain certain your specific circumstances. Sometimes you get some time to get information is to specific remains focused on a different ecosystem because service rendered architecture is not such a it's not an overly common thing in written in a

realistic ecosystem as it is in st.joe bar. Net ecosystem. And so you're probably going to find a lot of resources that are too focused on eye-catching the to focus the people that wrote them not to focus or somebody ever in the rails ecosystem. And so it when you find things are two specific you end up driving down a Wikipedia Rabbit Hole trying to map some of these Concepts to to something. That is that that we might find in a ruby gem. Other times you get stuff is just too vague. It's too theoretical. It's it's so high

level that it there's nothing actionable in is in these Google result. So That's a lot of times. It's because they're trying to avoid the situation where there where they might end up being too specific. And then you get a lot of this stuff about how if you're not doing if you're not doing services this way, then you're not actually doing Services. There is an unfortunate amount of that out there in India service running architecture Google results. The problem is that is that that's unnecessary gatekeeping and it falls squarely into the

no true Scotsman fallacy, which is that if you aren't doing something a certain way, you're not actually doing it, then it's not categorized as that thing. And so there's no another downside is that there's no real convention around is as real developers. We love our conventions. We like being able to install a Jen and we just get a lot of a lot of functionality out of the box, but there's no way to just say gem install, SOA and you get a service-oriented architecture for free. So after I wrote this after that slide

turns out they're sure enough. It was Justin Searles. And it's not even real so. So there is no real convention around this but there is there are a lot of a lot of fun fun attempts at this and there are there are attempts like Neo conference talk like this and there were there have been a few other really focus conferences about about services, but nothing kind of like to get you get you going there's a a lot of a lot of stuff that's that's that's focused in different areas and then maybe in in your in your

specific situation. But on the bright side, you're not locked into any specific into any specific implementation of a service rendered architecture. And that's one of the one of the really nice things about about not having convention is that you end up you have a lot of freedom anything that you end up incorporating into your system is not locking you into there and their implementation. So but there are a lot of common patterns that you'll see in service work in service rendered architectures. The main one is that your rails app that your building is no longer the

center of the universe. It's not okay. It's not the most it's not the only important thing to your working on. It's now just a single component of a larger distributed system. Dress up art 111 pattern is that your services might survive Jason or some other machine readable format and maybe the Consumers Energy Services might be something that your end users are are consuming from your API and it might it might be something that that you're that you that your own services are consuming

from other services inside your system. Sometimes they might serve HTML that is that's rendered rendered from various parts of of difference of different services, and then all just kind of like bundle together to destroy to to your and your edges. Some of your services might run on Rails some of them might not be real they might for a much smaller microservice. You might you might be using something like Sinatra road instead. I need to know how you going to be at all. They might beat. They might be when you talk into a remote service. You don't have to use the same

programming language for the both sides of that conversation. You might use that need a lot more performance. You might use a programming language that has a typically more perform at runtime like go or Alexa or Crystal. And maybe they don't even speak. I should you pee at all they might they might they might talk over a different over different interface and we'll talk about that in a little bit. Some of your services could be stateless way of saying that they don't have a database they might usually when you're talking to a stateless service, you're actually telling it to

perform an action you're saying this either I want you to do this or this thing has happened and you should respond to it. On the flip side of that they were making a distinction about stateless the opposite it going to be stable. And so this is this is just saying that there it is during some sort of data somewhere. It is it it might be storing it in a traditional SQL database. It might be storing it in but it doesn't it somehow it doesn't matter to you as a consumer that service

how they story you. Just need to know that you can fetch data from this from this particular service. If you're us if you're unsure, if you're building a service like this and you're unsure, what's what's our database to use the fact that the fact that I mentioned it doesn't have to be sick if you're unsure what to use to dispose dress. You're off to Google. Thank you. And your services can I can call out to other services? You don't have to necessarily be the the terminal point of that of that

if if somebody makes a request into your service and you don't have all the data inside of your own dentist, or maybe you can call it to some other services. This is actually very common pattern or we'll talk about that. No, love it, too. so that's a kind of High-level, very brief overview of what service rendered architecture is we're going to go into a little bit more detail in the next. So when we talk about monolithic architecture is one of the things I wanted to do was I wanted I wanted to grab a definition from the dictionary which

is as is tradition with it with dictionaries. The word is defined in terms of itself. So all of relating to or resembling a monolith is the definition of Monolithic. Thanks Webster. I also noticed that it says huge or massive. Those are those are two of the two of the other adjectives that are associated with monolithic grills UPS overtime over especially over, you know, 5 to 10 years will start to start to get really large and incorporate a lot of functionality. Alpha really like this definition formed from a single

Crystal aggravate But mainly the definition is that you think of the application as one piece. There is only one one thing that you're kind of developing testing and deploying as a single unit. But no matter what no matter what a man with a cap considers itself to be the most important thing in the universe. A lot of a lot of us are built with this idea and coded into itself into the DNA. Whether that's explicit or implicit, whether it's intentional or unintentional unintentional, this

is actually a really common pattern where if you decide to start separating things out later this might get in your way. So while you're working on something like this, if if you think I might be a possibility that you might split things out into multiple Services later met one at like as you work through through through daily tasks. You might want to think about this this particular part that I'm working on is this going to be something that's going to that would block us from suffering this out. Another another fun thing about monolithic Ives

is that truly monolithic what that looks like in this in this example, so we have to have a user visiting your real right user makes a request with a browser. Wilson Tech response seems pretty simple. However, we are overlooking quite a few things. There's a lot that happens in between. When that request comes in we need to know what to send back in our in our group now and racp response. Do because a real that doesn't keep everything in memory or in his local file system has to reach out to something else and that case this is this is

most likely our database by convention. We're probably using storage SQL database backend. And then the database Returns the query results to a rails app. Which then converts those that tabular data that we get back from from postgres into something that are domain object can handle inside of a real witch that we that package into HTML. So it probably seems pedantic to consider the database to be to be a second. You're at might also send emails to so that users can receive things like receipt or notifications since we don't deal directly with SMTP. We're not actually we're not actually

processing that email ourself. We're sending it off to a third-party email service. So we had a note a note for that in our in our graph here. We don't want to send emails in the course of what request because it takes too long that adds too much latency to our response. So we actually want to kick that off to a background job. So we had a note for sidekick in Ark but a real Siri doesn't talk directly to our to our side graph or chart to a psychic process. We're actually sending that into redis and psychic as reading Reddit. 20% payments so we had a

payment processor. And any production system needs logging era tracking system metrics and consumer site Analytics. It would make 1/4 from cashing on certain resources to reduce latency under load or improve group, but still be in the Cash Store to provide provide that for us. I will probably want to provide faster than full text search so we had a datastore that provides that as well. It's only our monolithic are single single piece app now has 12 pieces. 8 of these can be considered fully-fledged services to the rails up in the sidekick psychic

process. In the rest of the rest of them all of the pink notes on the graph. We we integrate with over known channels usually over http. And a four of the other four of them are there data stores that we use to generate our our responses to our Rosa. And this is just the more common real. Configuration nearly. Every real life I've ever worked with in production has this has been this kind of structure. None of them are truly monolithic. And so really a monolithic architecture is more about centralization the the the reelz app. In this crap is really just us at the focal point for all

of them for all of our Oliver stuff. Most of the data will end up passing through that real real server at some point weather is coming through one of the data stores or or we are passing it through to our email processor things like that. Where is service oriented architecture is are mostly decentralised. I think mostly nearly every service are willing to talk to us. We have what are a few of what are known as God objects. Usually these are things like your user model and whatever other model in your in your

in your in your app that your business revolves around such as product orders for an e-commerce application. In a service has approached. He's got an object actually become their their own full on Services. Typically that you that that you end up needing to talk to every star system. I've ever worked with had some sort of user. So whether that whether that was included authentication or was just about identifying users by ID. And usually this because that you need to have some sort of centralized repository for all of these all of these users. That's a hold the whole single source of

Truth idea. And so another Central piece of this might be at what's up? What's called a service registry different implementations of the simplest ones are basically just posted Hash Hash as a service where you just kind of like register all of your it's it's basically centralized configuration. Right? So you have you have all of your all of your services are names are the keys and the values of that hash are either the URLs or some get some some other configuration protocol information that you might use to to communicate with that particular service.

And this way when you use a service registry all you need to do in every service when you deploy it is to configure the service registry URL are or how are you communicate with it? So that that everything else can be discovered? But otherwise the system is is pretty decentralized. We have this set of services in an e-commerce application. Each service might actually have all of its ability to each of its own processes for handling web requests pending background jobs took so might have its own sidekick and its own process first just

running recurring tasks and also noticed that each service that we have here has its own has its own datastore. So it'll have its own application database and Ash. And so you don't want to see you definitely don't want to share it if it's between multiple Services if you don't need to and there are a lot of reasons for this from here. I have a lot of them in my notes. So if you took multiple databases care services multiple Services share database who owns the migrations like which which one of these

Services got is. Are you running rails DB migrate on? And when you do run the migrations, do you have to does deploying this this update and deployment migration? Does that require going through and rebooting all of the services that that depend on that database? If you need me test connection limits, you might end up running running into those connection limits to look for nipple Heroku postgres. You have 500 connections that you can use and that's it. Like there is no amount of money. You control a Roku for them to raise that number. You can run into that very quickly at

multiple Services share a single postgres database. And so each service also typically have different requirements for the day. And putting them together can have unexpected consequences in our e-commerce application that we were looking for e-commerce that we're looking at a little bit ago. If a developer on the catalog Services service notices the customer that calculating the average customer review on every request is very expensive because running aggregate queries on every single page load right that would get very expensive to they add a column inside the product

able to denormalize that and have you have a the average customer review in this pre-calculated. Maybe once a day more than I don't know. And then now instead of having to run the aggregate queries on every on every request they are they are like that. They're just reading another attribute off the out of the table. Within a developer on the cart service notices that the price table now contains the average customer review, and they start using in their responses as well because for whatever reason they have a use for it. Within the catalog team notices that running those

calculations slows everything down because aggregate craze are very expensive and up and updating the database millions of rows at a time cuz you're probably running is all at once that can slow down performance across the board. And so what they end up doing is that they extract that from postgres and move it into something something like a key-value store that that such a service that was using that column needs it and it crashes because they call him that they were depending on remote with remote. Depending on how much they've

become to depend on that column. There might be no no quick fix for that. And so You definitely always always always always want to have a separate database for every single service if you can. Another thing you want to do is be like, you do want your your your all your services to have the run run has super Campbell if if we're running sidekick, we don't want to share a reticence. That's with all of all of her other services to run the same psychic or to run different psychic because we if we miss can figure something we're suddenly we're grabbing other

people so I could job and that's Tuff Stuff real quick. Additionally, you also want to have a separate cash for each service. So having having a separate cash if if you share a cash with multiple services and one of those Services constantly update some cash with with new data and using some sort of like least recently used cache invalidation strategy that service is going on. Let everybody stuff all the time. So you definitely in order to keep your cash it

right High you want to have a separate cash per service? So now we can we can really go for it any further without kind of jump and kind of bleeding over into the communication. So that's where we going next. That's the most the most common pattern that I've seen for communicate between Services is to have some sort of machine readable format. Usually Json being sent over http. If you're communicating with a Java Enterprise service, for example, you might be using XML. That's still extremely common

situations. You might Jason might be too heavy. It can be a can be very expensive to serialize and deserialize Json so you might end up going with with something like message pack or Google protocol buffers instead. But let's say you're let's say your musicallys are facing webpage builds a an HTML page from all the data pulled from the user catalog and and card services. So uses that uses the use of service to identify you as a user based on the your your cookie data. The catalog service to show you the product catalog for

your eCommerce application and cart service so that it knows what all items are in your particular cart. Send all that noticed the names were using or not. Like we're calling this music service because users are kind of kind of specific. They're cut they're kind of a special case because we typically need user data for the sake of getting user data. But we don't call the catalog service. No call the products service will call the cart service the line-item service database tables. Those are the lower-level details that the that these particular Services revolve around

but if we start calling them by the by the names of of the what we would call the SQL tables that we put them in all we've really done is distribute a database across multiple systems or mobile services using HTTP that we can't do joins on. The so the cat but the catalog service here may have some overlapping data with the cart service also, so we're not doing it just for just for the sake of being able to join we're doing it because sometimes there are overlapping concerns. Even if even if he thought each service might need a separate view of the data there might be some overlap

between them. Super Temple the cart service when you add a product to the cart. It may actually reach out to the catalog service and say catalog. Can you give me the information about this thing? It's in a card. Play CCP doesn't fit everywhere. Fruit from for 1hp is a point-to-point protocol. So you need to know who you're talkin to. You need some at anytime anytime. You're first performed an operation. The other services need to be notified about you would have to reach out to them to tell them and so at

that point whose responsibility is it? Getting on our side now. Okay. So if if if service a performs an action and a b c and d need to know about it is it is responsibility to reach out to be sending or is it BC and he's responsibility to figure out some through some other through some of them that that happened. One of the other problems with using with using it to me for everything is performance. You either need to maintain a connection pool for every

service that you that you talk to or or you pick you end up paying the cost of a TCP handshake TLS negotiation and TCP slow start for every single request you make to it to every other service you might be surprised at how much more time is actually spent in in this initial process in the protocol overhead. HTTP request typically typically require waiting around for the responsible for the Standard & Poor libraries are optimized for synchronous asynchronous. I owe you may want to ignore it offer

for the sake of performance, but that's because you are going to get a response back and we synchronous IO that's the return value of of that call in forgiving the Ruby net ACP library is the response. Totalitarian examples conceptually, when we what we think of this what we think of when we say a nice to reach out to be C&J. We think that it's sending all these were all these requests at the same time. But really what's happening is a reaches out to be friends request and then wait for

response and then B responds later. And then of course we sent out a request. We should their we wait for their response and it would get it back. And you do the same thing for our last service and wait for the response. This is this can be a matter of milliseconds in seconds or even seconds. Asynchronous IO is difficult to do in Ruby like if we wanted to send out all three and wait for them and wait for their sponsor for all three together. That's just it's just not a really common pattern in Ruby and it's actually kind of difficult to do we end up having to write having to use

separate gems that are that are optimized for asynchronous I have and even then we need to consider all of the all the dependencies so for example in In the end in this example, how do we remove this the synchronous dependency on all these? Like I'm sorry. If we sent a request to be that would that the response of that is used in the request to C&D? How about like if we're using asynchronous IO we have to kind of mixed patterns. We have to use synchronous il-41 and asynchronous for the others

in order to get the best performance. So if if this is hard to do at the language level or at the at the Avi level, how do you how do we remove this? That's the kind of think this secret has all these the most common ways to use something like a message bus in this also. So if service a doesn't talk directly to be C&J, but instead just pushes this information into a message boss that b c and d also consume a no longer has has to know that b c and d depend on this on this result. We just kind of shut out a message that says hey this thing happened or hey, I need whoever

is whoever is responsible for this to do this weekend of throwing data over the wall. This also so that patterns is known as publish subscribe or Pub sub. Pubsub is kind of like a slack workspace which like Mars is inhabited entirely by box. I actually built a demo of this of this using slack as a message was for the stock but had to cut it for time. I'm already I'm already cutting it close as it is, but if you if you if you want to see this, I will try to post a screencast over this weekend after I've had some time to decompress after the

conference. So the puzzle pattern publishing a message is like sending a chat message in slack each bought subscribes to a set of channels. It could be one channel could be all the channels or somewhere between and will receive every message that comes through linearly. Hopefully ideally chronologically. Don't do that in production in the service or bought received the message you might perform an action which could include updating some of its internal data or sending one or more messages in response back into the message queue back into the slack

channels. Is it illegal to use for things like sending imperative messages like this sort of thing that you would use a side job for or notifying other services does something happen? This allows us to bypass HP enforced request response pattern without rewriting or services around a paradigm that our language just doesn't have good support for the moment. Another benefit of this is that your service doesn't actually have to be reachable over the Internet. Nothing is making connections to it. So he's not as like as not receiving incoming connections. So it doesn't need to be registered

in your service registry or anything like that. I don't need a domain name or a static IP address. It it's consuming stuff from from a known source. So this means it doesn't matter whether you run this on Roku or you know, some of that some of their platform or it runs on a Raspberry Pi that sits on your desk. Also is also awesome because the next time somebody responds to a bug report with works on my machine you steal their laptop and wired up the production and start consuming production. So these are just a couple of the communication patterns that

we went over. We have machine-readable formats. Like Json being such a crazy to me. We have to look into Mobile HTML fragments being sent over HTTP and communicating asynchronously over message bus. This is not an exhaustive list. This goes way deeper into a broader than this but this is this covers about 95% of use cases that I've used. And so now we're going to get into the trade-offs of of using a service rendered architecture over something like a monolithic rail. One of the big trade-offs is latency when latency is the time it takes to perform

an action. Once I'm in throughput is how many times you can perform that action in a given time. You get a lot of throughput by Distributing your work across a lot of a lot of different services, but the more services that you need to talk to you before a particular action can complete the longer it takes You're dealt. So what would have happened if you're delegating work from your machine off to another machine to free up CPU Cycles on your machine? And there's the time involved in serializing this and sending it over the wire but normally normally you gain a lot of throughput for that

and also milliseconds. Nobody might even notice the the increase in Lindsay, but as your system involves this might grow into a whole lot of milliseconds as you had several layers of Energy Services, I want to say layers of services. This is kind of what I'm talking about. This is a this is a service for a fat Netflix. They are they have a few ed services so I can only talk to you are the ones closer to the left. I think the the the farthest to the right is the one labeled API. That's the that's any of us go the rest of that

is all internal services. everything the whole the whole lot right hand 2/3 of this is that is there a microservice soup so Another thing is another thing that you have to you have to work around is your team structure when you when you go from a monolithic to microservices architecture is that you might organize your teams around around the concept of be services. There will likely be little to no overlap in each team's functionality in each team's responsibility. So they'll probably be working on the same subset of services and not a whole lot of a

whole lot of cross-pollination between them actually leads his team thinks I load and then so you have to keep that in mind and have some mitigation strategies to keep talking to each other so they don't become too insulated. It also distributed systems are a lot of work. Once you start going down this path you end up needing one or more people whose entire job it is to keep that that entire architecture talking to talking to keep us from talking to each other. The end of coordinating with developers managers to make sure that the interfaces between those Services stay

consistent. And help them help them work around different trade-offs that they don't doubt. They'll need to make in their own communication powder. One of the one of the largest maintenance burdens of disturbing systems is that you lose Adam atomicity guarantees, and this is release the fancy term for the entire thing happens or the entire thing does not happen. Usually inside of a SQL database we would use transactions for this. We don't have that when these transactions are now spanning multiple set multiple multiple system. Furniture, for example, let's say a user needs to add an

item to the shopping cart. So you publish a message saying I do next to their car and they're adding two of them should have clicked the quantity to button. And so Yep, they're just so so so they click that button. We generate the message on our in our web app. We send it off to a message bus Which then publish is it to both of these Services the inventory and the car service. But then the inventory says you will only have one we can't add two to the card. So that's not going to happen.

So we have to we didn't have to implement we call compensating actions, which is like that that inventory service has to say has to say sorry. This is this isn't happening and that the car service has to respond to that in the wet in the web service might need to I need to display an error message. So then you also have to what this means you have to think about every single action that gets published through your message bus and how it can be rolled back a lot like active record migration. You have to write the up and the down. Another big thing is uptime.

This is going to be a large straight off because now if you because now the uptime of any individual service in your system is the product of the times of all services. It depends on so in early Centralia scenario where we had a depending on b c and d talking to B C and D directly if each of these Services has three nines of up by 99% uptime or 8 hours and 45 minutes of downtime per year. A service that depends on three others will see you will then have a full day of of downtime per year. If we had a fourth dependency, that's nearly a

day and a half. And cereal dependencies are even scarier. So in this scenario if be blows up a can't do anything. even worse if any of these Love in This chain, none of the ones to the left can do anything and so liken the situation assuming each service would have three nines of uptime like 99% 8/8 hours and 45 minutes of downtime per year. If we do, dependencies then a goes from 99.9% to 99% flat that is over 3 and 1/2 days of downtime each year and it which is literally ten times

as much downtime as it would have otherwise And this is meant to scare you away. Like down time is inevitable. You don't need to know what but you do need to know what you're signing up for when you when you choose this sort of architecture. And so that you can you can allocate extra time and money on mitigation strategies for downtime. And they're there to there is a silver lining to this. In a man with the girls up running tests and deploying might take anywhere from several minutes to a few hours depending on the size of the size of the application at

my company the time for one of our services Will a smaller services to run the CI build and deploy production after we merge a pull request or question commit is 29 seconds. When you have when everything is much smaller and much much narrower scope your tests the time the time between the development and production becomes much smaller. Is this the sort of the voice be Timmy Timmy critical in that be absolutely crucial when you accidentally deploy a show-stopping bug? And development and testing a single service on others can actually be

really tricky. You may need to step out some of your dependencies. If you think about all the times that you had to use the VCR gem to step out things request to remote Services third-party services. You now have to do that for your own service all of your own services that you depend on. sometimes this might mean that you deploy development cluster to use to you to use and development and something else to run to run your CI against So if you communicate with all these other services asynchronously though your message, but it's actually easier to test

because you need you just need to test that you can that you can respond to in a given message once a message comes in. You you perform that action and then you can make a sessions on that on that either that that process or or the result of that call. And so forgetful if you have if your car serviced you working on your car serviced and it has a an add to cart message you might want to ensure that a given product has been added to the user's card and that's it. That's the whole the whole processor. And so that's that's to their level three. We made

it moving from a centralized architecture to a decentralized one and I would love to chat with any of you about them because I really I really enjoy talking about this turn around if you. And let's chat about what you're working with. And that wraps up would have got there still so much that I couldn't cover here, but I appreciate you all for listening to what I could I'll name is Jimmy Gaskins. You can find me on Twitter handle and thanks everybody.

Cackle comments for the website

Buy this talk

Access to the talk “RailsConf 2019 - Service Architectures for Mere Mortals by Jamie Gaskins”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “RailsConf 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “IT & Technology”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
173
app store, apps, development, google play, mobile, soft

Similar talks

Matt Duszynski
Senior Software Engineer at Weedmaps
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Ben Bleything
Developer Advocate at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Christopher Sexton
VP Engineering at Radius Networks
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “RailsConf 2019 - Service Architectures for Mere Mortals by Jamie Gaskins”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
644 conferences
26393 speakers
9799 hours of content