Logging

Summarized using AI

Winning in Production

Dr. Nic Williams • February 10, 2016 • Earth

The video titled "Winning in Production" features Dr. Nic Williams speaking at RubyConf AU 2016. The main topic revolves around the challenges and insights gained from deploying web applications in production environments, particularly focusing on Ruby on Rails and related technologies.

Key points discussed in the presentation include:

- Historical Context: Ten years ago, it was challenging to deploy Rails apps, and many developers were unaware of production environments. Dr. Nic reflects on how far the community has come since then.

- Barriers to Deployment: The lack of clear guidance in deploying Rails apps remains a significant barrier. Deployment was often seen as a concern because of infrastructural limitations and scale.

- Evolution of Hosting Solutions: The introduction of platforms like Heroku made it easier for developers to get apps into production without worrying about infrastructure.

- Importance of Being Production-Ready: Dr. Nic stresses that developers must focus on production requirements from the start. A Rails app can signify commitment, making effective development practices crucial.

- Container Technology: The emergence of Docker and its integration with platforms like Cloud Foundry highlights the importance of consistent deployment experiences for developers.

- Demonstration of Deployment: Dr. Nic provides a live demo showcasing how to deploy a Ruby on Rails app on Cloud Foundry, emphasizing simplicity and efficiency.
- Monitoring and Logging: The presentation discusses the necessity of logging, allowing developers to gain insights into their applications post-deployment.

- Developer Responsibility: Developers should not just focus on coding but actively care about the user experience and the final product in production.

Dr. Nic concludes with key takeaways on fostering empathy among developers regarding user experience and the significance of providing a stable production environment from day one. The core idea is that successful deployment is about creating an accountable culture among developers that focuses on meaningful problem-solving in a rapidly evolving technological landscape.

Winning in Production
Dr. Nic Williams • February 10, 2016 • Earth

RubyConf AU 2016:

RubyConf AU 2016

00:00:00.320 Ten years ago, I was a lot younger, and I remember this is not me. That's David Hannah Hansen, who looks very much like that from that angle, still today. He's Danish, and it was awesome back then, and it still is today.
00:00:11.470 You could build a web app even if you knew nothing about programming. It would generate HTML, and if the HTML went into the browser, it looked fantastic. But ten years ago, knowing how to deploy a Rails app was something known only to a few, almost like a secret held by a small community living on a mountaintop.
00:00:35.520 I don't know where that mountaintop was, but it certainly felt that way. And this leads me to my first lesson about winning in production: You can't win in production if you're not actually in production. It's interesting; I started blogging a year later, but if you look back through my blog posts, none of them discuss running things in production because I couldn't do it for years, and that was really embarrassing.
00:01:00.000 Now, I'm confident enough to share that 10 years later, there are barriers to winning in production, and one significant barrier is that if you don't know how to do it, you're likely to struggle. Even now, I don't think the Rails codebase provides clear guidance on how to deploy. It represents just a small part of a much larger stack that you might know nothing about.
00:01:14.880 You might get distracted by things like React or any other JavaScript framework that sits on top of it. A question that we used to ask at Ruby and Rails conferences ten years ago was, 'How many of you get paid to do this?' That was synonymous with asking, 'Are we allowed to do this?' Back then, running on someone else's infrastructure was a significant concern. Many companies wouldn't even consider it.
00:01:44.800 I remember seven years ago, I was in a pub in Sydney where Ruby discussions often took place. Tim Lucas, a wonderful human being and the founder of Buildkite, introduced me to a phenomenon emerging from America. He was the first one to inform me about Donald Trump, which was interesting. Additionally, we were learning about Git, but it also involved pushing apps into this new platform called Heroku.
00:02:05.440 Heroku was fantastic because from day one, your app could be in production. We had consulting clients who were happy because they could see their app and didn't have to come around to connect to my laptop anymore. Back then, good Rails apps lived and died on Heroku, and it was free, which was quite handy. However, the barriers to longer-term deployment were still daunting.
00:02:35.680 What does production mean? It's a five- or ten-year journey, much like raising a child; it doesn't just start on day one. Rails’ new command should definitely include a warning that says, 'You've just created a production app. Did you mean to?' It seems harmless, but it's a big commitment.
00:03:00.480 So, when something didn't work on Heroku, there was nothing you could do about it. It was often proprietary, so you wouldn't know how it worked or how to fix it. Sometimes, you simply grew out of it. The 'Are we allowed to?' concern persisted because, back then, running on someone else's infrastructure was a barrier for many companies.
00:03:57.440 Even if you did get permission, the pricing often became a problem at scale. Regardless, it was a wonderful learning environment. About five and a half years ago, I moved my family to America on short notice because my wife once said, 'We will go wherever you need to for work,' but apparently, America wasn't one of those places.
00:04:37.440 When we arrived, we met a diverse group of people. America is so funny. At that time, I went to work for Engine Yard, one of the largest sponsors of Ruby and Rails, at many conferences. A lot of us who didn’t necessarily use their services were grateful for their existence. They had some of the biggest apps and successful companies running on their platforms. I wanted to learn from that.
00:05:13.440 In this talk, however, I want to focus on some of the negative experiences. Until recently, CI pipelines were becoming easier as people built products other than Jenkins. We couldn’t make it easy for everyone because, even though you could have massive production environments, you couldn't effectively create small development environments. This often left developers working only on their laptops.
00:05:44.800 One of the funniest tweets I ever saw illustrated a sysadmin telling a developer that something wasn't working, and the developer replied, 'It works on my machine!' It emphasized the unfortunate reality that many developers were blissfully unaware of the production environment.
00:06:09.000 One of the challenges we faced at Engine Yard was that we gave everyone Chef access and root access to machines. While this might sound innocent enough, you have no idea how they'll extend the platform. This could lead to contention, particularly regarding Nginx configuration, where everyone had their theories on what should happen.
00:06:53.280 This contention made it very hard for us to evolve the platform with confidence. Over time, I felt that Heroku's model of container-based abstraction was a cleaner approach than the full virtual machine approach. One idea was to encourage developers to get onto the platform from day one.
00:07:26.320 This relates to the stories of both Heroku and Engine Yard; it's about developers deploying from day one and learning how to navigate the constraints they faced. For example, MySQL is not on the same machine as your app. These constraints are pivotal for making quality production choices.
00:08:12.640 While living in America, I was invited to VMware's Palo Alto campus, where the Cloud Foundry group was experimenting with adding container support. They were rolling out a tool called Bosch, which was exciting. However, there was this other concept called Warden, which unfortunately didn't gain traction because it was born at VMware.
00:08:58.400 Despite their nature being fundamentally beneficial for development and operations, VMware didn’t quite know what to make of it. In due time, we saw the emergence of Docker, which reignited the excitement around containers, though containers themselves generate more VMs.
00:09:37.200 Nonetheless, the evolution of container technology became significant for both operations and developers. I also saw ideas from Cloud Foundry that resonated more strongly than those I'd seen before. It was open source, and they even made Bosch open source, meaning you could run it in your data center—essential for large institutions.
00:10:29.920 Financially, you could start from the adoption of open source along with consulting services provided by companies like Pivotal. The cloud foundry product proved to deliver a consistent deployment experience across its hosted and on-prem options. This consistency means that regardless of how you installed or operated it, the deployment experience was the same for the next five years.
00:11:18.080 As a developer, you were responsible for ensuring that your app conformed to production requirements from the very beginning. This principle is fundamental to my belief about winning in production. After obtaining my new visa, I started something with Stark and Wayne, which greatly emphasizes the importance of Cloud Foundry in helping us grow.
00:12:12.000 At Stark and Wayne, we witnessed significant growth, expanding to over 25 people in a short span. I could monitor diverse customer environments, and I found there were over 5,000 applications deployed, some of which were running different pipelines.
00:12:52.640 The people utilizing this platform could create their own CI systems and orchestrators, allowing for diversity and integration. Cloud Foundry and Heroku made it easy, providing developers with a consistent API to work with, which fostered excitement and innovation across teams.
00:13:27.200 I found it fascinating to observe the invisible problem spaces these companies tackled. The fact that Cloud Foundry was moving into the Foundation was significant; if VMware, which became Pivotal, opted out, there were numerous other companies investing in the project.
00:14:09.840 As a consultancy and believer in a chosen platform, my excitement about this transition grew. We got a new logo, which is always a sign of importance because it often indicates significant changes.
00:14:50.720 Everything was going fantastically, and I moved back to Australia. When I arrived, I didn't quite understand the complaints about the national broadband network until someone advised me, 'Just wait for NBN,' which clarified the frustrations linked to connection issues.
00:15:36.880 I often discuss Cloud Foundry with enthusiasm, and people commonly ask to see it in action. I learned from this feedback to ensure that I demonstrate the deployment process, which now shall be showcased.
00:16:12.000 For this demo, I will show you deployment on a vSphere cluster located in Europe, connected through a VPN. It includes Cloud Foundry, MySQL, and AWS access. I will not pretend to type everything during the demonstration.
00:16:42.720 I find it exhilarating to create a Rails 5 app. A controller must be established first because no default homepage exists anymore. I love generators; they simplify the development process significantly.
00:17:40.560 Once the Rails app is created, deployment is quite straightforward. It requires just one command, as I've already targeted my Cloud Foundry instance. The push will upload the source code, creating a route for access.
00:19:02.320 When the code is pushed, it checks the default build packs, similar to the Heroku model, determining that this is a Ruby application. Personally, I believe this deployment process is more straightforward than setting it up on a local machine.
00:19:47.680 Once the app is live, you can receive warnings, which help developers understand how to curate their apps better for production. Logging becomes paramount, allowing developers to actively monitor their applications.
00:20:37.840 This focuses fervently on the logs your application produces, providing valuable insights into production dynamics. I like to utilize a logging system like Papertrail with Cloud Foundry how it integrates so effortlessly.
00:21:41.680 Binding services within Cloud Foundry allows us to connect our applications to various logging services. Your application does not need to understand the underlying logging infrastructure; that’s the beauty of this platform.
00:22:50.080 As we wrap up, environment variables are essential; they facilitate configuration without needing to push sensitive information, maintaining security and adaptability during deployments.
00:23:28.520 Ultimately, the core ideas entail offering a consistent production experience from day one. If embraced and understood, this perspective fosters accountable developers who help their companies succeed.
00:24:07.920 In summary, I outlined three primary goals aimed at elevating developers. Developers should focus on meaningful problems rather than mundane tasks so that companies can thrive against competition.
00:24:55.680 Ultimately, fostering empathy among developers and users is crucial. We aim to help developers care about the user experience in production. This finish is vital in today’s tech environment where Docker and cloud technologies are rapidly evolving.
00:26:00.000 Being able to use Docker with Cloud Foundry platforms offers a pathway for effective deployment throughout the development lifecycle. Achieving this means you can truly win in production.
00:26:41.760 Thank you very much!
Explore all talks recorded at RubyConf AU 2016
+15