Yup. All of it.
05 May 2015
02 May 2015
We all have see them; most of us have to deal with them; many of us contributed to writing at least one of them. Legacy code bases tend to evolve over decades and will with rare exception get messier and more entangled as a function of the number of people working on the project and the lines of code they produce (a phenomenon that seems pretty consistent with the rest of the known universe). My company was recently challenged to take our ~17 year old code base and make a fundamental architectural shift from a more traditional layered monolithic architecture to a micro-service one. Coupled with that architectural goal, we also want to start moving as many services as possible to public cloud providers in order to take advantage of the elasticity that the cloud can provide.
13 Mar 2015
I’ve been going around to different teams inside of my company recently and talking about how we’ve gone about the task of selecting different tools and technologies for our projects. I figured that if this many people inside the company were curious, there may be some value in sharing it with you good folks as well. So here, I’ll attempt to cover the principles, strategies, and technologies for both our development process/pipeline and our projects themselves. And as always, I would love to hear your experiences - especially if your experience provides insight that can help us further improve the ways that we do things.
06 Feb 2015
I’ve been trying to get caught up on my backlog of things that I generally like doing but haven’t been finding the time to do recently, and a current project at work has me working in the same technology on which this blog is based - so it gave me a convenient excuse to - yet again - try and revive this blog. We’ll have to see how well I do in keeping up with writing. I find that in the world of tech bloggers, and trainers - but more on that in a later post - people fall uneasily into one of two camps: there’s the folks who work day jobs as practitioners and then keep up with writing out of the pure joy or catharsis that the activity may provide. There are also folks who write because it’s either a part of their job or because it’s a marketing activity to promote their job (e.g. training). I would aspire to be in that first category and while I have nothing against those in the latter category, it’s just not really for me. If I’m going to err on a particular side, you should expect that this blog will go silent while I’m up to my eyeballs in building and learning.
01 Oct 2014
I’ve been kind of quiet in the weeks since leaving Microsoft. It’s been a good quiet - in fact, the best kind of quiet there is. It’s the quiet the results from being completely overwhelmed, engrossed, and excited about the challenge ahead. I’ll describe some of these challenges over the next few weeks in more detail, but one of them is about making large scale architectural and technology shifts. Specifically, my team is out in front, figuring out the best way to design and build lots of interoperating large-scale services that run reliably and cheaply in the public cloud. While we’re certainly open to suggestions regarding our technology choices, at present, we’re envisioning a stack based on Unix design philosophy - and as such, our current stack is Linux (currently CentOS, but really interested in CoreOS) + Docker + NodeJS + MongoDB/Couch/Postgres + a limited number of AWS services like S3.