Posts

Showing posts from August, 2018

Building a Resilient Cloud Application: The Network Layout

Image
This is the first of a series that I want to breakdown the different components of modern day applications that operate around the world, and has become easy to deploy with the cloud. The Network Layout Regions Around the world, the big cloud have graciously put the effort to build the infrastructure to host your applications in just about everywhere in the world. In order to organize a set of systems, each provider offers various "Regions" that you can set up your cluster. For example AWS has setup 16 different regions all over the world, from US-WEST-1 in Northern Calfornia, to US-EAST-2 in Ohio, all across the world to EU-CENTRAL-1 in Frankfurt to AP-SOUTH-1 in Mumbai. For a full list check out their availability regions listed here . Regions are responsible for isolating your application to a particular region. An application deployed to one region will not be available in another region. We use this principle to isolate failure and to have higher control of

The Scalability Cube

Image
I was just watching a YouTube video where they brought up an interesting diagram, which I realized summed up how to scale your service from an system design point of view. In the diagram, it has three axis: X-axis scaling (Horizontal Duplication) Y-axis scaling (Functional Decomposition) Z-axis scaling (Partitioning) Horizontal Duplication (X-axis) Probably the first thing that comes to mind when your thinking about scaling out your application. Horizontal Duplication means that you should build your application in such a way that you can have multiple instances of your application running and handling requests at the same time. To complete this strategy, a machine called a load balancer will usually sit in front of your cloned systems and forward incoming requests to your instances.  Stateless Design Stateless Design is the design principle that information is not stored from the communications between a user and an instance of your application, and this informa

Where Do I Want to Go?

I wanted to do a slightly different post today, and I wanted to talk about something that I thought was just as important to your career as technical knowledge, and that was your motivation. A few days ago I had an interesting conversation with a coworker about what motivates me to work like a dog, even though the company is the one that's reaping all of the benefits from my work. I told him the idea that motivated me is that " Don't think about it as your working for the man, think of it as I got somewhere to go, and this is the path I'm taking ." By turning in around, you can internalize that you are in control of your own fate, and that the actions you do will move you to where you want to be. Take the opportunities that life gives you and make it part of your journey. Once you start to think you are not in control of your own destiny, I believe that's when you become jaded and lose out on the opportunities that life gives you. It keeps me going durin

Docker, a Container Solution

As software develops and matures, so has the tooling around how we interact and use our software. One of those technologies that has started to become widely adopted is the usage of Containers for deployments. A container is the idea that you want to bundle all the necessary components of your system such that it will create a consistent run-time environment wherever it is deployed. Docker Docker is the most widely adopted container software in the industry. With docker, you specify all of the components of your system, which may include: - Application Code - Libraries and Dependencies - Frameworks and Run-times Which get bundled into one package that is deployed to your servers. How does Containers differ from Virtualization? Containers and Virtualization can solve some of the same problems, such as separating the domain of your applications and utilizing physical hardware more effectively, but they are implemented differently, and therefore have different benefits and dra

We Eating Good Tonight (Week 4)

Last week had a lot of surprises. I went into the iHerb interview thinking we were going to explore new technologies and white boarding scenarios as the meeting invite suggested, but instead it was a code fest, and I was expected to write down as much code as possible in a given amount of time.  Needless to say I didn't feel totally prepared, and I thought that I didn't do that great on that section. But apparently my expectations for myself and what they thought were different, and the recruiter said I continued to impress them. Following that I received the offer on Thursday, and today I signed it back. This means I will be moving on from my time at Tallan and starting my new career at iHerb! I think moving forward I'm going to tone down the amount of posts as I get ramped up on the new position, and also bring a bit of balance back to my life. I'll probably try to post 1-2 times a week. I have some written notes on Kubernetes and Docker, and a writeup on NoSQL

RabbitMQ: A Look into Messaging Queues

RabbitMQ and Messaging Queues Messaging queues plays a large role in the communication channels of large enterprise systems. A message queue/broker is an added system that stores a queue of messages between multiple systems.  Message queues will bring general consistency to your architecture by providing a delivery mechanism that ensures the proper delivery of your messages. To integrate message queues into your architecture, we're going to have to re-think how we connect our services together. RabbitMQ is a popular framework for implementing message queues within your system, although there are alternatives such as SQS or MSMQ. Components Messaging Queues consists of three main components. Publisher - This is a system that emits some message within your environment. The message is then stored to the message queue. The Message Queue - A system that stores the messages in a queue to be consumed by other systems in your environment. Consumer - A system that takes