Time for reviews

It has been suggested to me recently that, since I’ve been buying and selling my electronic devices rather regularly, I should start doing some kind of reviews. And the more I thought about it, the more it made sense. I did have a go at it a long time ago, but ultimately did not follow through.

Well, this will not be meant to be a comprehensive review, as you will be able to find that in a ton of websites, but more of my own personal take on what I feel is good and works well for me.

As such, it will be very opinionated, as it should be. If you know me and trust my taste in electronics, then follow along for the ride, I promise that any disappointment is not intentional.

Things I’ve learnt about microservices

Over the past couple of months I’ve been working on and reading up extensively on microservices. Numerous medium articles, and 2 books* later, here’s just a quick summary of the important points that I’ve learnt.
*Building Microservices – Sam Newman / Microservice Architecture – O’reilly

Is it suitable for me?

Organization

The organization that you are part of is a very huge part of whether the microservice architecture (MSA) is suitable for your project/product or not. Conway’s Law states that software design often reflect the organization communication structure, unsurprisingly, the inverse holds true as well.

While not a fact set in stone, there is less resistance when implementing MSA if your organization embraces the agile culture. I feel that this is mainly because MSA is an evolution of Service Oriented Architecture (SOA). Having small teams with defined roles and objectives helps with separation of concerns and works in line with the technical aspect of MSA.

Sense of ownership

This is also closely linked to the organization and culture in general. MSA is not a magic bullet that could solve all the issues with the moving target problem. The team(s) need to take ownership of the service that they are building. There is no hard and fast rule that one team should only handle one service, but the team that built the service should be the one in charge of maintaining/improving it.

There are many other factors that I won’t delve into as the books do a much better job as putting the information across. But briefly, the other factors are as level

  • Location of team (across countries)
  • Team size (2 pizza rule)
  • Outsourcing (cultural fit)
  • Competency level

So you’ve thought through all of these factors and decided, “I think my team/organization is ready for MSA, where to start?”

Continue reading “Things I’ve learnt about microservices”

Things I’ve been exploring

Haven’t updated this blog for half a year because… I was actually writing it in a private blog. It’s mostly incoherent ramblings on the new frameworks/languages that I’ve been learning, trying to sort out my thoughts the whole time.

But there are a few key takeaways from the past couple of months since I’ve started working at Govtech.

The project that I’m working on utilizes the micro-service architecture. Which everyone know it’s a buzzword these days. However, to actually implement it in the way that works out as well as the bigger players like Netflix, Twitter, etc; is a heck a lot more difficult than I naively imagined it to be. (will probably have a separate post about micro-services cause it’s too much to write about in a single post)

Here’s the list of technologies that we are using, and pretty much all of them require me to pick up from scratch.

StackPurpose
Spring bootBackend framework
React Redux SagaFrontend framework
ELKLogging/monitoring
GitlabCI/CD
AWSInfrastructure
TerraformInfrastructure as Code
AnsibleIT automation
Kubernetes/DockerContainer orchestration
AirflowScheduler (haven’t dive in yet)

Because of what I’ve been working on, I have decided to revamp my January home server setup again. It’s still in progress because I can’t get my Kubernetes cluster to initiate correctly and it has been driving me bananas.

In this period of time I have also revamped my portfolio page to be more modern and doesn’t have slight misalignment that the previous layout had. The reason it turned out well is probably because I got tired of trying to do everything from scratch by myself and just used a well-known framework, Bootstrap. (Fun fact: It was built with pure CSS grid layout and ES6 generator functions)

In any case, I think I will make an effort to write here more often instead of dumping everything on a private blog. After all, sharing is caring right?

New server setup for 2019

First post of 2019, it’s time to dive into what and how I have my server configured. Well technically it was configured in 2018, but it took awhile to type this out.

There are 3 main services that I want to run, however in total I’m running a total of 6 docker instances on my DigitalOcean server.

It was rather smooth sailing, apart from the disaster that broke out right before I wanted to migrate this WordPress blog. Most of the Docker images that I’ve used came from linuxserver.io, they provide really good and clean images that have been used by millions of people. (I’m just too lazy to build my own images)

Continue reading “New server setup for 2019”

When this site crashed

My WordPress blog crashed when I tried updating it to the new Version 5.0. I swear I could hear a woman screaming in the background when I realized that everything stopped working. It also turned out to be way more difficult to recover than expected because I was running multi-site on it.

Gutenberg simply crashed everything

Basically, the new version of WordPress refused to play nice with the presumably outdated version of Gutenberg I have running on my semi-neglected blog. It crashed everything, including my other private sites I have running on this installation.

Continue reading “When this site crashed”

Introduction to Terraform

As I’m going to be interviewing for a job that works on this platform, I’ve decided to read up on what Terraform is (as well as Nomad, but that’s for another post). This is actually something I’ve wanted to explore for awhile now, but haven’t had a good reason to get into it yet.

Terraform is very similar to AWS’s CloudFormation, which is basically Infrastructure as Code. However, the main advantage is that Terraform is platform agnostic, which means that I am able to use the same tool to deploy on multiple, different cloud providers. The catch however, is that the code is obviously different because services are different on different providers. Terraform basically just provides the platform/tool to manage it all in one place, but it’s way more powerful than that.

After watching a few talks and going through some documentation, the concept makes a lot of sense, and it might actually be pretty easy for me to deploy my own projects through this. Even though it would be a little pointless to use such a tool to deploy a single instance, hah.

I’ve watched two talks about Terraform so far.

I gotta say, my mind is a little overloaded right now. But I am very impressed with how he managed to bring up an entire infrastructure across different platforms and region in <10mins. It’s also amazing that by SSH-ing into the bastion host, he was able to have access to all nodes across different regions, and schedule services to launch on them without switching regions. (thanks to the VPN)

I am excited to see what type of projects I could test deploy with this new tool.

VueJS > React for smaller projects

Holy crap it has been 3 months since I last wrote something. I guess in the midst of being busy I lost the feel/drive to keep this updated.

Well, apart from those 2 short posts about Javascript, a whole lot has happened. Firstly, I gave up on using ReactJS for my capstone project. There’s a list of reasons, but I gave up mainly for 2 reasons.

  1. It takes too much time to develop something simple with it
  2. No boilerplate/templating within the framework means that it’s fast, but also means that I have to write a lot of native JS over and over again

Those 2 reasons, combined with the complexity of scaling with React correctly according to best practices got my head into such a spiral that it’s simply not worth the effort.

Instead I went with VueJS under the recommendation of my friend. And I gotta say, I managed to code with it way faster than React. Simply because there is a ton of templating code that reduces the amount of pure JS I need to write for simple things like looping. A v-for loop is much easier than a map function, where I have to deal with the type of objects and data type.

Side note: Set up a new server at my gf house. First time I’ve set up a physical server that I have access to somewhere else other than my own home. I don’t know what I can do with it yet, but it felt awesome because I felt that my knowledge is applicable in places apart from my own setup.

Immutability

So this is a concept that I have known for a while but have not been sure why it’s such a good idea. After going through a few documents and watching a 30 min talk I think I have a better understanding of what it’s all about.

Basically, you do not want your object to mutate. Because when you are not sure what has changed. For example,

let A = 1;
doSmth(A);
console.log(A); // What is A here?

It totally depends on what the function does and it is difficult to track how the values have changed over time. The library that I read up on was immutableJS, this library uses a Directed Acyclic Graph internally to represent the values internally. It makes sense because DAG will never point to a node causing a completed graph. The implementation is cool but shall not go into that.

So basically, the benefit of using an immutable data structure is that it allows me to compare between two objects much more efficiently. Because of the way DAG works, it can answer the question of “what changed?” very quickly. You can ensure that updating a variable do not cause weird bugs in a different portion of your application, because it’s not the “same” variable.

If it seems a bit confusing, it’s because it is and I’m dying. To the point where I actually need to write things down like these to remember what the hell I’ve been learning.

Till the next puzzle piece.

Redux: action creators

Because of the sheer amount of information that I’ve been researching on lately, I need to write it down somewhere before I forget all the shit that I’ve learnt.

Action creator is best used with the container-component pattern (smart/dumb). Basically the action creator separates the responsibility of creating the action within the component itself when you need to dispatch the action. Instead, you split it away as a function, and call it whenever you require to use it.

This is why it’s great to use this with mapDispatchToProps because it just works well together and you’re just passing a function from the smart to dumb.