Month: October 2018
Recently the new hot buzzword seems to be “serverless”. There is a meetup group called “Serverless NYC”, and there have been a few “Serverless” conferences. Lambda is the new tool from Amazon that gets thrown around by developers at every meetup. But what are we talking about exactly? Just to be clear, even though the name is serverless, when you eventually get to the bottom of the tootsie roll pop, there is a server there. It’s just about who controls it.
The people who are using the services provided are still running their work on someone’s server.”With a serverless architecture, you focus purely on the individual functions in your application code. Services take care of all the physical hardware, virtual machine operating system, and web server software management.” This allows the developer to focus on being a developer, and not necessarily require the extra skillset of knowing, Linux, networking, and infrastructure. Since the focus here are functions, it should probably be some smaller project, or something that can be independent of the scope of a larger project.
The benefits of a serverless architecture is no need to deploy or administer any servers, install software, or run updates. That is handled by your provider. If you need more compute you can just purchase more consumption rather than build and deploy new servers, even if just virtual machines. You don’t need to architect for availability and fault tolerance since that too is built into the architecture you are buying. Availability would refer to your service being up, while Fault Tolerance would refer to withstanding the failure of a sever.
With every upside there is a downside. Some of the downsides of serverless computing are: 1) multitenancy problems, which means that if the provider over provisions their resources and available compute is limited, it will affect your services. 2)vendor lock-in: if you design your services around the capabilities and api’s of provider A, then it makes it much harder to move to provider B. 3) security concerns – you don’t really know the status of the security of your host. You trust your provider, but for those with the need for absolute control or some regulations, they need to make sure the solution is viable for their needs.
While there are some downsides, there are many potential upsides. Serverless is here to stay and should be weighted as a viable solution for any deployment.
When I first looked up Passenger, a Gumdam-like robot icon appears. From the site itself, “Battle-hardened by some of the most demanding web apps for over a decade, Passenger is considered one of the most performant, secure and mature app servers currently available.” (1)
OK so what is it? Passenger is an open source web application server which handles HTTP requests, manages processes and resources, and enables administration, monitoring and problem diagnosis. But then question is, if I type “Rails S” why would I need passenger? Passenger doesn’t replace “rails server” in the sense of it being a test platform only. What “rails server” does is it uses an application server – such as Passenger – directly to server ruby files.
The default web application server activated when you use “rails server” is Puma. Looking at the Gemfile, you can see “gem ‘puma’, ‘~> 3.7’”. I think this is a great thing to realize, a lot of new Rails developers need to not only know about how to write code in Ruby and Rails, but also about the ecosystem that runs a web application, instead if using Heroku as a crutch. Standing up a server on a standalone box can be a great learning experience. With Linux you would use Nginx/Apache to host pages, as they are web servers. They provide the HTTP transaction handling and serve static files. However, they are not Ruby application servers and don’t run the Ruby applications by themselves directly. Nginx and Apache are used with an application server, such as Puma or Passenger. What application servers do is make it possible for Ruby apps to speak HTTP. Ruby apps (and frameworks like Rails) can’t do that by themselves. So we need the application servers so the ruby apps can talk to http. But application servers aren’t as good as Nginx and Apache at handling HTTP requests because Nginx and Apache are better at handling I/O security, HTTP concurrency management, connection timeouts, etc. This is why a good Rails Engineer will still need to know about Linux, Apache, and Nginx.
Why choose Passenger over Puma? Passenger’s strength is that is also can host Python, Node.js, and Meteor apps as well. Passenger is the best choice when you have apps developed in several languages that Passenger supports and you want to consolidate your app server stack. Puma’s strength is that it’s easy to configure and mostly “just works” out-of-the-box. I think that after getting familiar with what Puma does, its better to look at Passenger for growth cases