Summarized using AI

Services Inception with Ruby

Dave McCrory • September 29, 2011 • New Orleans, Louisiana • Talk

Summary of Services Inception with Ruby

In this session presented at RubyConf 2011, Dave McCrory discusses the concept of service metaprogramming in Ruby applications, particularly in the context of Platform as a Service (PaaS) environments. The core idea focuses on how Ruby applications can dynamically interface with various services to streamline deployment and management tasks, which often involve provisioning numerous backend resources.

Key Points Discussed:

  • Service Metaprogramming: McCrory introduces the concept of service metaprogramming, emphasizing how Ruby code can be designed to interact with other services, including databases and APIs, that are critical for the application’s functionality.
  • Dynamic Resource Allocation: He explains that just like WordPress allocates resources dynamically for blogs, Ruby applications can dynamically create essential instances (like MySQL or Redis) only when required. This behavior can significantly reduce mistakes made during deployments and help in managing application dependencies efficiently.
  • Examples of Service Consumption: McCrory references the Heroku platform, illustrating how it enables rapid application deployment (e.g., the creation of 34,000 apps in just 24 hours) through simple commands like curl requests. This example underscores the speed and efficiency of utilizing PaaS offerings.
  • Handling Service Dependencies: The talk includes a discussion on managing service dependencies effectively. McCrory highlights that applications often rely on several services, and understanding these dependencies is crucial for successful application operation in a hosted environment. Example services include databases (e.g., MySQL, PostgreSQL) and messaging queues.
  • Provisioning and Configuration Management: The session delves into how Ruby applications can utilize a RubyGem for managing the provisioning and de-provisioning of these services. By encapsulating configurations within the application code, it helps developers visualize what their applications rely on and manage environmental conditions more effectively.

Conclusion

The main takeaways from McCrory's talk are:
- Service metaprogramming allows for greater flexibility and control when interfacing Ruby applications with essential backend services.
- The ability to provision services on demand directly relates to reducing deployment complexities and errors.
- Understanding the service dependencies of an application leads to better-managed Ruby applications in PaaS environments. This approach is an evolution towards more coherent and easier deployment methodologies in modern application development.

This insightful session ultimately encourages developers to rethink how they manage service dependencies and application configurations in Ruby, paving the way for a more responsive and adaptable development framework.

Services Inception with Ruby
Dave McCrory • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 12, 2011
Announced: unknown

Ruby code creating services for it to then consume aka Service Metaprogramming A very large number of Ruby apps are deployed in hosted environments. Many of these hosted environments offer both internal and external services with APIs that your Ruby app can consume. The problem is that the use of these services often requires provisioning tasks for each service and the service must always be there or the app will fail. This session will show Metaprogramming Ruby code and a RubyGem for provisioning/de-provisioning, binding/unbinding, sharing configuration state, and more. This allows your application to create a Redis or MySQL instance only if needed (say on initial startup) or bind to a specific service, but only if/when it is present. This approach eliminates many of the forgotten steps during deployments and makes it easier to understand what your Ruby code really depends on because it is all encapsulated in the application's code itself!

RubyConf 2011

00:00:13.759 thank you
00:00:17.279 so this is uh Services Inception
00:00:21.539 you can go ahead and get started
00:00:24.779 yes and happy obligatory cool animated
00:00:30.000 first slide so I'm Dave McCrory and uh
00:00:34.260 we're going to talk about some
00:00:36.059 interesting Concepts around applications
00:00:38.780 and uh and how they interface with
00:00:42.780 Services specifically in platform as a
00:00:45.780 service
00:00:46.879 some of this is going to seem kind of
00:00:49.379 complicated I'm hoping I can boil it
00:00:51.840 down so that you kind of watch it build
00:00:54.420 on itself in uh hopefully at the end we
00:00:57.960 can have some uh kind of almost a
00:01:00.059 brainstorm session I'm really looking
00:01:01.980 for feedback around what the best
00:01:04.559 approach is conceptually to achieve this
00:01:07.920 so the first thing is I'm sure you're
00:01:12.060 all PHP programmers right and you've
00:01:14.460 done Lots with WordPress
00:01:17.360 the concept behind what you do with
00:01:19.860 WordPress when you get started and you
00:01:22.020 click on a Blog is effectively you get
00:01:23.939 your own instance of a Blog so that's
00:01:26.100 kind of uh you're getting something
00:01:28.259 dynamically allocated to you uh based on
00:01:31.560 your request so that's kind of the core
00:01:33.960 of what all of this will end up being
00:01:36.240 about so I with the help of uh with the
00:01:41.040 help of Dr Nick actually tried to think
00:01:42.840 of one of the easiest things that you've
00:01:44.460 all probably done something like this in
00:01:46.979 the past so it'd be easy to uh to begin
00:01:50.100 with
00:01:51.060 so if you've heard about uh 34 000 apps
00:01:55.740 by Heroku in 24 hours
00:01:57.920 this is a way of doing that on Demand
00:02:00.780 with a curl request so if anybody wanted
00:02:04.380 to Loop through this 34 000 times you
00:02:07.740 could you two could have 34 000 apps in
00:02:09.899 in 24 hours on Heroku
00:02:14.340 so
00:02:15.540 if you've ever used platform as a
00:02:17.640 service and when I talk about platform
00:02:19.080 as a service I mean all the different
00:02:20.940 platforms is a service that are out
00:02:22.500 there so I don't care who it is if it's
00:02:25.260 Heroku engine yard Cloud Foundry if it's
00:02:27.959 you name it it doesn't matter they
00:02:29.940 they're all effectively providing you a
00:02:31.860 place to push your code and some type of
00:02:34.260 uh what what I'm calling services that
00:02:37.080 you can consume those Services could be
00:02:39.120 other applications they could be
00:02:40.680 databases or message cues or workers or
00:02:43.860 whatever it doesn't matter they're all
00:02:45.599 services ultimately and I at least
00:02:49.620 believe that in the future that's going
00:02:51.000 to be one of the few things that
00:02:52.080 differentiate all of these Technologies
00:02:53.819 anyway it's going to be what services
00:02:55.680 they provide and how they provide them
00:02:58.560 but effectively what happens is you push
00:03:01.379 your code up and you get an app and the
00:03:04.980 app ends up having something that's
00:03:08.640 allocated at a set of resources so
00:03:10.739 that's where your app's deployed
00:03:13.140 the provider on the back end isn't just
00:03:15.599 spinning up your app uh it's probably
00:03:18.000 spinning up something if you're putting
00:03:19.920 a rails app or something else out there
00:03:21.540 like that you're getting a MySQL
00:03:23.459 instance or something else that's spun
00:03:26.159 up now an instance might be simply a
00:03:29.040 database instance where you're just off
00:03:31.319 to the side or it could be an instance
00:03:32.940 like a virtual machine or something else
00:03:34.800 but it's still a resource that's being
00:03:36.959 allocated that you can that you can
00:03:38.700 consume and then ultimately your app is
00:03:41.220 able to use whatever that resource
00:03:42.900 happens to be
00:03:44.420 in effect it's the same things when we
00:03:46.920 just saw the WordPress right it's I'm
00:03:49.200 spinning out a resource that you can use
00:03:51.060 in this case I'm spinning out two and
00:03:53.040 then I'm connecting the two together
00:03:56.819 so setting the stage so you'll see
00:03:59.640 littered throughout this references to
00:04:01.560 Inception in case you're curious so
00:04:03.840 you'll you'll be tortured with that
00:04:06.120 um so like I said the whole talk is
00:04:08.519 specifically around talking about the
00:04:10.980 problems around pass there are all sorts
00:04:13.860 of ways to control these interfaces to
00:04:16.320 these services and request provisionings
00:04:18.239 to happen sometimes they're baked into
00:04:20.579 the application and sometimes you have a
00:04:24.780 greater level of control sometimes you
00:04:26.280 have less level of control but you do
00:04:28.020 have control so from a command line with
00:04:30.419 most of the platforms that I can think
00:04:32.220 of at least you can create a service or
00:04:35.160 you can push an additional capability or
00:04:37.800 an app or you can turn a capability on
00:04:39.840 or off
00:04:41.460 which is really handy
00:04:43.919 um so it's interesting in the fact that
00:04:47.400 and I'm not going to read any of this to
00:04:48.900 you I'm not going to torture you like
00:04:50.280 that but uh
00:04:52.500 what happens is they're dependencies
00:04:54.900 when you push an app out onto one of
00:04:57.300 these platforms and I don't mean
00:04:58.919 dependencies is in Ruby gyms or
00:05:01.199 libraries or however you want to look at
00:05:02.759 it like that
00:05:03.900 I'm talking about the service
00:05:05.400 dependencies so you depend on these
00:05:07.320 other things it could be redis or
00:05:09.540 or MySQL or it could be you know amqp it
00:05:13.740 could be you name it it these are
00:05:15.540 dependencies they're just dependencies
00:05:17.400 on either other servers other
00:05:18.840 applications or or other services that
00:05:21.540 exist
00:05:24.539 somebody has to set those Services up
00:05:26.460 not all of it's automatic you do get an
00:05:29.400 instance uh with somebody like Heroku
00:05:31.680 you get a postgres instance these days I
00:05:34.320 think on Cedar so you do get you do get
00:05:37.320 some resources for free search
Explore all talks recorded at RubyConf 2011
+55