I’ve been working on building and installing Kubernetes from scratch and during this process I followed a guide on the CoreOS website called CoreOS + Kubernetes Step By Step. In this guide they demonstrate using cloud-config to install SSL Certs on the core OS operating system. Altho this makes the guide simpler; by doing this I have found it encourages bad behavior. This is because when you trying to scale the solution one immediately starts reaching for a configuration management systems to handle installing a SSL Certs and binaries onto CoreOS workers/masters. This is not what you want!
I picked up pdf copy of Sam Newman’s book, Building Microservices. Since I’ve had some experience with SOA and microservices I thought I’d take a look. I’m really glad that I did, it’s a great book! The following are some quotes from the book and my thoughts on the subject.
“With micro-services, we can make a change to a single service and deploy it independently of the rest of the system.” — If multiple services rely upon a single service, you can’t just change it inside a vacuum, deploy it and expect dependent systems to never have problems.
Due to the collaborative nature of git; over time I begin to accumulate quite a few branches and working closely in a team compounds this problem. Remembering what branch needs to be merged, and what branches need a pull can tax the little grey cells.
The following instructions are for setting up devstack in a VirtualBox VM.
First we install the python cinderclient module
These instructions have only been tested on Precise Pangolin
Since the US observes Daylight Savings; every year we take 1 hour from the spring and give it to the fall. As the old adage goes we spring forward in the summer, and fall back in the winter. When we fall back, which is at 2:00 AM on the first Sunday in November we introduce the ambiguous hour. This year the ambiguous hour lands on November 6th. The hour is ambiguous because at 1 minute after 2:59 it’s 2:00 AM again. Even tho it was 2:00 AM 1 hour ago….
To understand why this is might cause problems,
Standardization is a tool used by companies to make their resource pool more flexible. For Example, if project X needs more bodies to ensure it meets a deadline, management has a larger pool to pull from and divert to the suffering project. The other promise is of reliability and consistent metrics; the idea goes – the more things run and look the same, the better your metrics and repeatability will be.
I just spent the last 30 minutes debugging a mock object. I was running unit tests through the debugger and inspecting the objects I thought the code was calling. To my surprise this well-defined well-used object was returning an un-expected result in the tests. Only later did I realize the test wasn’t calling the real object. It was calling a mock, and the test writer had incorrectly defined the mock result.
More people are realizing that beyond the hype, the cloud can be a real game changer. But how that effects each tier of the software stack I think is up for some debate. Deciphering the future path development is something of a mystic art, of which I will attempt to partake.