Too many decisions perhaps

12 Aug 2015

It takes alot of decisions to create a production ready web service. I’ve been coding for a while now, and I’ve seen alot of different configurations, requirements for up time , service level agreements, and various business and environment level constraints. It has always felt like that it should be easier to build a web service. It seems like we only have a few concerns, but in reality the amount of decisions to make are quite large. I’ve decided to just list out a bunch of them to illuminate the situation. Simply put its too many lowlevel decisions, trust me they’re important but at somepoint we have to build simple constructs that allow us to safely and cleanly concern ourselves with higher order ones.

These are a serious crap ton of decisions to make, engineers at startups make them all the time, the world we live in should be simpler, docker is helping to tackle the problem build system, and potentially cloud/no cloud issues. Whilst CoreOS and mesos help more with reducing the amount VM planning. In an ideal world you’d really like to write the application , and have the run time usage just grow the rest of the pieces of the system. That’s not quite possible yet, perhaps because we don’t have higher order enough abstractions, that build off of simple constructs to allow us to structure things more clearly. I shouldn’t be thinking about ways to circumvent a 64k connection limit on an ethernet card , or increasing the file limits on the OS. I should be thinking about my application alot more.

Databases
Technical
  • Read/write throughput
  • Transactional/ Non-Transactional
  • Paging / buffering
  • Locking Characteristics
  • Maintainability
  • Memory Usage
  • Scalability
  • Cloud/No Cloud ###### Business
  • Cost
  • Maintainability
  • Scalability
  • Durability/Longevity
Virtual Machines

- ###### Technical - Memory - Ethernet Cards / ip addresses that can be bound - Bandwidth - Hard Disk storage - OS/ OS distribution/ version - CPUs/ Cores - IOStats - Durability - Deployability - Reliability - Cloud/No Cloud ######Business - Cost - Maintainability - Scalability ##### Caches/CDN - ###### Technical - Memory - Bandwidth
- Read/Write speed - Eviction Policy - Cloud/No Cloud - Scalability ###### Business - Cost - Maintainence - Scalability ##### Application - ###### Technical - Memory - Threads/ No Threads/ Green Threads - Architecture - Division of Services - Logging infrastructure - Build System - Testing infrastructure - Standards to employ coding,dev practices,lang. stds - Languages - Deployment ###### Business - Time Cost - Cost - Scalability - Maintence - Reliability
###### Extras - Security

comments powered by Disqus