· devops startups

Picking the right framework

It has all been done before

For someone starting out building applications for web/mobile/etc, it can be absurdly difficult with all the choice. Should you use Ruby? Python? Haskell? Elixir? C? Rust? Go? Erlang? Node? PHP? Java? How about frameworks? Ruby on rails? Flask? OK, perhaps choosing is too difficult. What about a nosql database? 225 and growing, so not easy. Perhaps it would be easier to figure out a deployment model between containers and paas and configuration management tools? Or front-end development frameworks?

Luckily, it is not all that important. New does not mean necessarily better, but you have to have a good overview of what you are doing and why.

For instance, every story has been written and every tale has been told. Did you know that every plot can be broken down into seven basic plots?

We are probably not going to do it better than our predecessors. There are reasons for that - concentration, speed, and memory which anecdotally has been slipping over time1, but before I digress and start telling tales of my youth where I went to school walking uphill in the snow both ways2, the same keeps happenning in an accelerated cycle in the software world. It is quite the microcosm, a universe to itself, if you will.

As far as I can see, there are major cycles and the fundamentals of how to build things stay identical given the context of systems engineering which now has a shiny new name - devops. In the context of product development, systems engineering is referred to as a process of value-stream maps. In fact, I should probably write about systems engineering. However, repackaging does not make something novel, it is just a new application of an older, more fundamental technique3.

The software world keeps oscillating between server vs client architectures and sharded vs monolithic data sets. With the onset of cloud computing, we are currently in the cycle of sharded data sets and thin clients (SAAS). While the capacity of RAM is growing, there is also a large proliferation of clients (IOT). Whether all these devices need to connected to a central mainframe which holds all the data (aka. gmail) is a different story, but as usual, things will change. There is also a fundamental need to account for network speeds across locations and a movement towards privacy.

So what happens when storage devices become as fast as memory or memory becomes as cheap as disk? Why would someone want to use map-reduce algorithms when they can do an in-memory sort?

What will likely stay the same…

Having watched this a few times now, here is what I have gleaned:

And translating that to plain english in the context of web development, you probably do not need to deal with petabytes of data or billions of concurrent connections, and it is easier to scale up than out, so the minimum toolset would include:

The good news is that the languages and technologies do not really matter, it is whether you have a good foundation. The problem is that a good foundation comes with experience. And experience is what you get when you don’t get what you want.

tl;dr - Keep it simple and go out and build things.

  1. Some ancient Greeks complained of the ability to write and take notes since it would decrease the amount the youth would need to remember. I imagine they would shudder at the thought of google. [return]
  2. Ironically, true. Both my school and my house were on hills and I had to walk through a large valley to get there. Once during a snowstorm, I kept slipping down the hill both on the way there and back. It was a rough day. [return]
  3. I recently had a fascinating conversation with someone who worked next to Dr. Hamming of the Hamming code and spoke about how mercury delay line memory and dram were fundamentally the same. [return]
  4. http://www.extremetech.com/extreme/203490-moores-law-is-dead-long-live-moores-law [return]
  5. I admit it - I do not want to figure out why there is some write contention under high loads. Or check the return value of malloc 10 times a day. [return]
  6. It is too difficult to write in node.js. Make your life easy and don’t do it. [return]
  7. We have more compute power in our phones than Deep Blue to render some data and graphics. [return]
  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket