https://matildah.github.io/posts/2016-01-30-unikernel-security.html
Single address spaces: design flaw or feature?
Leave a reply
The limitations of sampling profilers today, with glimpses of tracing tools from the future
Seveneves
Last night I finally finished reading Seveneves (Indigo, Amazon) by Neal Stephenson. I don’t know, or really want to know, how many pages this beast was (I bought the digital version) but it even though it was very compelling it still felt like it took a long time to read. I found myself staying up later than I planned several times.
If you liked The Martian you will like this book. It’s slightly less ‘sciency’ and has more of an epic feel. The odd part was that I got into it enough that I started to view the world through the book’s lens. After you’ve read it you will understand.
9/10 – Well worth the time investment.
P4
I mentioned P4, a data plane programming language the other day. I’ve linked to a good overview paper below if you are interested.
In-band Network Telemetry
I’ve done a bit of research into P4 recently. Figuring out if the IP-[TCP/UDP] mono-culture is here stay is a long-term interest of mine and P4 is perhaps one way to break that mono-culture.
One of the use cases presented for P4 is in-band telemetry. None of this really requires P4 but it’s interesting to think about hardware driven implementations.
Google gcloud and API rate limits
Lately we’ve been making use of the Google Pub/Sub service at work. During development I ran into continual problems with API rate limits doing a modest number of API requests.
After some investigation with the Google support people (we have Gold support) it turns out that if you use the default authentication provided by the ‘gcloud’ command in your local development environment, you get different rate limits than a service account does.
I lost a lot of time trying to optimize for these API rate limit errors. Hopefully this little note will stop someone else from having to go through the same pain.
A couple weeks with the Nexus 6p
As I wrote a couple weeks ago, I switched to a Nexus 6p from a Samsung S6 mostly because the lack of software updates was frustrating.
Here are a few random thoughts on the Nexus 6p now that I’ve used it for a couple weeks:
- The hardware build quality is almost as good as the Galaxy S6. Certainly better than the Galaxy S4.
- The screen is quite nice but the colors are a bit weird until you turn on the developer options and enable the sRGB mode. This really should be the default setting.
- No un-installable carrier bloatware and Samsung apps is a big plus. Not being able to delete the Bell TV app or Microsoft OneDrive (because Samsung made a deal with them) was stupid and annoying. It also highlights how little respect Samsung has for the end user vs. trying to please the carriers.
- The raw benchmarks on the Galaxy S6 beat the Nexus 6p but the 6p feels much faster during normal use. I don’t know the cause for certain but to whatever extent this is a result of TouchWiz, Samsung should just quit trying to do user facing software. They are horrible at it.
So far my experience is that the Nexus 6p is an upgrade from the Galaxy S6.
Microkernels are slow and Elvis didn’t do no drugs
Oh Samsung
My Galaxy S6 finally got Android 5.1 today – that’s 9 months after the 5.1 release date and almost 3 months since Android 6.0 came out.
Too late. After four Galaxy Ss (1, 2, 4 and 6) I’ve already ordered a Nexus 6p which will arrive tomorrow. I’m done with the slow software updates. Nice hardware though.
Python, Asyncio, Docker and Kubernetes
In the last while I’ve spent some time learning about Docker, Kubernetes and Google Container Engine. It’s a confusing world at first but there are enough tutorials to figure out it all out if you spend the time.
While doing this I wanted to create a simple micro-service using Python 3.5’s Asyncio features. This seemed like the perfect fit for a micro-service. To have a useful goal, I ported our code that synchronizes the NightShift application with Hubspot. This works fine but after having it running for a while I discovered that the initial structure I built hid the tracebacks within tasks until the program exited. Figuring out a high level pattern that addressed this took a lot longer than I thought would. To help spare others from pain, and to hopefully create a useful tutorial, I have created a Github repo called python-asyncio-kubernetes-template.
This little repo has all the files required to create a simple Python/Asyncio micro-service and run it on your own Kubernetes cluster or on Google Container Engine. The micro-service has an HTTP endpoint to receive healthchecks from Kubernetes and it properly responds to shutdown signals. Of course, it also immediately prints exceptions which was the original pain point.
The README for the project contains a simple tutorial that shows how to use this end to end.
Hopefully this saves others time. If you know of a better way to do anything I’ve done in this repo please get in touch or submit a PR. It would be great if this repo grew to become a definitive template for micro-services built with these technologies.
python-asyncio-kubernetes-template