Justin Brodley @ Google+

Day 3 at Daptiv. Things are going well, starting to figure things out.

Code deployment

As most Ops guys know Code deployment can be a challenge, especially when the code relase is dropping 100's or 1000's of changes to the product into production in one large code push. While I'm a huge fan of Devops and continuous deployments, realistically a lot of organizations are still deploying code the old fashioned way. Nate over at TechOpsGuys recently ranted about organizations that his company relies on pushing production code on friday and breaking his companies website (http://www.techopsguys.com/2012/02/03/dont-push-code-on-a-friday-damnit/). This rant brings up a few things i've been thinking about for a long time and felt needs to be expressed more clearly in a blog post:

1. Friday Code Deployments or Large code pushes are going the way of the dinosaur, more frequent smaller code releases with feature flags, continual integration testing, etc are becoming the norm.

2. If your software product is relying on services via API's for your product to function or provide availability you need to start thinking differently.

Code Deployment in Devops

With the push for Devop's in SAAS and B2C Business you are seeing more and more companies going to continous integration and continous deployment. In fact some software companies won't even show a new developer where the bathroom is until they push code into production. (http://www.scottporad.com/2010/11/01/cheezburger-network-doesnt-show-its-new-employees-the-bathroom-until-theyve-checked-in-code/)

Having been involved in code deployment for over 5 years in a SAAS environment, I much prefer the smaller code deployment without taking major downtime of a site or service. Rolling in features bit by bit and turning them on when their fully deployed or turning them on to a select set of beta users makes it so much easier to test features, functions, etc with real production load and know how these systems operate in production. Plus if you find an issue once you've deployed the code you can roll back to the previous code by redeploying from source or fix it and push the code out.

Relying on Third Party Services

Once you understand that code from a lot of startups is being deployed all the time (Etsy pushed 10,000 code changes in 2011 (http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/). You need to start thinking about how you integrate with these services differently. If you main home page pulls in a twitter status updates from your CEO you need to make sure the following happens:

1. When the API is functioning, display the data (Yeah i know Duh)

2. When the API is not functioning that the following happens:

A. Your website still loads and doesn't throw a nasty 500 error

B. Your website doesn't have an obnoxious hole with a 404 or 500 error in the sidebar or header of the site.

This means your developers must be planning for the inevitable situation that the API is going to break, the way you call the API will change, or plagues of locusts have infested their datacenters. Your developers need to focus on thinking about all states of the service and the behavior they want their application to exhibit when the failure occurs.

True SaaS and why you should care

Great article on True SaaS (multitenant, single code line, hosted software) and why enterprises should care about it. Its a common practice for software vendors with highly successful products to just assume that it can "be SaaS" if we just repackage the solution as hosted. While this may look "SAAS" and your customers may even like the appearance of a higher level of data security, it has huge trade offs in terms of an enterprises need to manage the solution. Customers of these type of solutions are tied to higher per user costs, they have to do their own upgrade coordination and scheduling, normally with high up front PS costs, and they suffer less than stellar quality and performance as they scale the solution. If your in the market for a SaaS solution you should be asking about the delivery model, if your not your doing yourself a disservice.

http://www.enterpriseirregulars.com/44507/what%E2%80%99s-true-saas-and-why-the-hell-should-customers-care/

Google Design Asthetic

I used to think Microsoft had terrible design aesthetic for their applications, but I have to say the new Google designs are downright HORRIFIC. They first attacked google reader this week with this grey on grey background, white space between everything, and an ok integration into Google Plus. Today they allowed you to switch to the new Gmail interface... which is just as bad as the new google reader color pallet, yep grey on grey. I seriously don't understand the design process at Google unless its completed by color blind engineers.

Come on Google!! Hire away some UI people from Apple, or hell even Microsoft and fix this!!

Why!!

Why has Posterous pivoted into a social network!! UGH... I don't need another Google Circles, Facebook or Twitter!! I just want to post stuff to you, point my domain at you, and have you distribute my content everywhere my friends live on the internet!!

Not happy right now!! Will give it a few days and see if I can cope with this change.

What?

Why not Vmware?

In the late 90's early 2000's there was a large push by major enterprises to modernize their ERP, CRM, HR and associated mission critical business applications. Oracle began acquiring enterprise software vendors like Peoplesoft, BEA and Seibel. If your interested in their acquisitions you can read about them here. In talking to my colleagues in Oracle shops they started the Mantra "why not Oracle" when new business requirements came up. A few years later with Virtualization gaining popularity I began hearing "why not VMware?" when talking about new server requirements and needs. This drive for virtualization rapidly dropped costs, allowed companies to be more flexible and eventually resulted in the new "cloud" age that we are in today.

I'm a huge fan of VMWare, i've promoted it to my colleagues, used it to save my employers money and ultimately built more agile IT teams to deal with changing business requirements. While i'm a huge fan, some of my colleagues are not pointing out the high price of VMWare licensing, additional complexity, and the 15-20% performance hit between Virtualized servers and bare metal. Having been an ESX user since 2.5 I've been a long time supporter, unfortunately with the announcement of Vsphere 5 I have to now reevaluate my entire thought process.

Vsphere 5 isn't the first time that VMware has alienated their customers, the first was "Enterprise-Plus" that was introduced with Vsphere 4.0. Enterprise customers had traditionally been buying Enterprise licenses for ESX after being told that it was the "premier license" that included all of the features of ESX. Vsphere 4 introduced Enterprise-Plus now going against the messaging from VMWare sales. Luckily while there were some compelling features in Enterprise Plus (vswitch, standardized host config, etc) and larger memory configurations 99% of VMWare customers didn't find these as critical features they must have.

Now with the introduction of Vsphere 5 they have added to their socket licensing model vRAM allocations. I understand the rational for this the major push in Virtualization shops is larger servers, with more cores per socket and lots of ram. This allows you to reduce your VMWare server needs and increase your consolidation ratios. With customers buying less ESX Servers this put VMwares cash cow at risk and they needed to take action. My issue is with their vRam allocations per ESX version, for Enterprise-Plus their "premier" license you only get 48gb of Allocated memory in your license. A server with 96gb of ram only costs around 16k from Dell right now, meaning that your VMWare licenses are now over 70% of your hardware cost! This is stupid, and is going to cause nothing but pain for customers and increase costs in a time when were being ever squeezed to reduce costs and provide more.

So, VMware has taken a page from Oracles book, get your customers invested or buy your competitors, and than jack up your rates holding them hostage to you unless you want to go to great lengths to migrate off your existing solution! VMWare is the new Oracle, and shame on them for screwing their loyal customers and advocates.