Dendory Capital - Blog

If you take any of the cloud platforms, you can spend days looking through all of the various features. AWS alone has over 212 core services. In recent years, a lot of those new features have been created to make it easier to deploy projects into the cloud, and there's nothing wrong with that. However, you have to realize that by using these easier to use services, the cost you end up paying will be much higher than it could be.
The problem with these one-click deployment systems is that they have to assume a lot of things. They deploy infrastructures in your name, including Windows or Linux instances, load balancers, DNS configuration, networking, and so on. While you can manually go in and tweak these resources, if you've relegated the deployment to Amazon, you might not want to then go in and start tweaking the result.
Yet there are many ways that deployments can be improved, both in efficiency and cost optimization, if you have somebody with deep knowledge of the offerings a…

The conversation with a company or recruiter typically goes something like this:
The work will be 40 hours a week, the office is in a nice building downtown... oh, and we even offer remote work one or two days a week. This is the wrong way to approach work in a post-pandemic world. In tech, we're lucky enough to be able to work in front of a computer from anywhere. Whether you spend most of your day in Microsoft Office, a code editor, a shell terminal, an email client, or pretty much any application, chances are it runs remotely, or at least accesses remote resources. We're well past the point where home broadband connections were a luxury and computer software needed extensive expertise to operate.
Instead, the ability to work from anywhere should be the default, and the precision should be for things that can't, or shouldn't be done remotely. Perhaps there's value in meeting some clients face to face. Maybe you need to go to the factory floor to handle physical devi…

Deploying web apps is core to a lot of what cloud and DevOps consultants do. Let’s face it, everything these days is a web app, and if it isn’t, then it’s a mobile app powered by a web app. Whether the web app is a simple set of PHP scripts with a PostgreSQL database, or a complex system of microservices, the deployment process is typically fairly similar. Here I’ll describe the high level overview of how I deploy such a web app to the cloud so it’s highly available, secure and the whole process can be replicated easily.Overall designBefore writing any deployment code, I need to decide what the design  will look like. This will heavily depend on the business needs of the project, but typically it will look like this:One VPC with at least 3 subnets: 2 private in different availability zones, and 1 public.One load balancer to distribute traffic to the web apps, in a public subnet.Two or more web servers, in different availability zones and private subnets, serving the web app.Tw…

A few years back, I built my first status screen using a Raspberry Pi 2B and an old version of Raspbian. Now, I repeated the task using a Pi 3B and the latest version of the OS. Since things have changed significantly enough I decided it would be worth writing another quick post about it.The result includes the date, time, current temperature outside, world and local news, and looks like this:The first thing to do is to connect a Pi to an old TV, which is what I did. Installing Raspbian should be simple enough and is described quite clearly on the web site. Once done, there are basically three things we have to do:Creating a status websiteTo make the actual web site, I used GitHub Pages. You can see the actual site I use here. The only file I had to create manually was the index page, which is a simple page that provides a black background, the needed styling, and some JavaScript functions to show the clock and refresh various parts of the page.Once the repository is created…

When I first started working with Amazon Web Services (AWS), it didn’t take long before I started to look for a way to automate the creation of cloud resources. This was years ago, when DevOps was only just starting to become a popular concept. Back then, the newly releases Boto3 Python library gave me the result I needed. Using Python scripts, I could make API calls to AWS and interact with resources. For example, creating a S3 bucket can be done with these lines of code:import boto3 s3 = boto3.resource('s3') bucket = s3.create_bucket(Bucket='mybucket') This had the advantage of being fast and providing an automated way to get a consistent result. In fact, I still use Boto3 to this day. However, this isn’t true DevOps because it doesn’t give you a way to track changes or destroy the resources linked to the script. Enter CloudFormation.When looking for a proper DevOps tool, I stumbled upon CloudFormation. This is Amazon’s answer to Terraform, a way to use t…