Operations | Monitoring | ITSM | DevOps | Cloud

Deploying a basic Serverless application has been made easy with the abundance of frameworks out there. If you’re part of a small team or working on a relatively simple project, setting up a basic serverless CICD process is also pretty straightforward, since there is plenty of information on the subject. But when a Serverless application grows it can get very complex very fast.

Have you ever been confused about the different ways to handle missing data in the Ruby language? I know I have, and I’m sure I’m not alone in that. The options Ruby offers come in the form of several methods: “present?”, “blank?”, “nil?”, and “empty?”. There are all somewhat related since all of them check for the absence of data in some way.

In my last post, I talked about the evolution of infrastructure as code and its role in modern software development. To recap, let's take a quick look back at what an IaC process establishes: in a nutshell, IaC is a methodology that enables you to manage your servers and deploy your applications purely through code. Through some configuration language saved to a file, you define the resources and packages that servers need.

With Serverless, it’s not the technology that’s hard, it’s understanding the language of a new culture and operational model. Serverless architecture has coined some new terms and, more confusingly, re-used a few older terms with new meanings. This glossary will clarify some of them.

Authentication for web apps is a difficult problem. Anyone who’s ever tried to create their own authentication system will tell you that there are a lot of unexpected edge cases. What’s more, your authentication system is an externally-facing part of your application. This means if someone is trying to hack into your application, your login system’s security will be one of the first places they check.

Like many startups, Stackery is a small team. For this reason, employees often need to go beyond their official job title to ensure everything gets done. As the Stackery product matures and gains more exposure, we’ve seen an increase in customer support inquiries and decided to further refine our customer support process through the creation of a customer support rotation that rotates amongst the software engineers on a weekly basis.

Today I’m excited to announce a new Rancher Labs project called Rio. Rio is a MicroPaaS that can be layered on any standard Kubernetes cluster. Consisting of a few Kubernetes custom resources and a CLI to enhance the user experience, users can easily deploy services to Kubernetes and automatically get continuous delivery, DNS, HTTPS, routing, monitoring, autoscaling, canary deployments, git-triggered builds, and much more.