Reaching for the cloud

On May 31, 2016, Posted by , In Cloud Computing,Engineering, With No Comments

Reaching for the cloud

It goes without saying planning, engineering and profiting from a cloud oriented software solution is an ambitious undertaking for any size organization. While many start-ups and enterprises alike actively peruse successful cloud offerings; only a few succeed in this potentially perilous quest. So how exactly did some of the more notable cloud success stories come about? Is it through some secret engineering sauce or illusive business equation? While there is no magic bullet or illusive formula, there are a number of battle tested practices that can aid in the development and delivery of a successful cloud product. In this article we will delve into cloud strategy and try and decipher the equations that have aided many businesses in succeeding where others failed.icon-saas_3

Basic SaaS Business Finance

As engineers, the finer points of sales and finance are probably not as interesting as tinkering with the latest automation tools or creating algorithms. All be it uninteresting, understanding the financial aspects of SaaS can help us better understand our role, our responsibilities and help us grasp the important journey we are on. Cloud offerings and SaaS solutions (as I am sure you are already aware) represent the future of the software industry. SaaS based dynamic vertical markets offer the potential to be highly profitable. However, large profit margins can only be realized if the costs surrounding the implementation of the SaaS product can be managed effectively and recouped through sales. To procure revenue generating income, investments in people, process and the product will need to be made by the business. In this sense the sales and marketing expenditures the business spends to gain a single customer are combined and averaged to determine the ‘Cost to Acquire’ (CaC). Cost to acquire is an important figure. It helps the business understand how much capital they will need in reserves to procure enough customers to gain a foothold in the market.

Once a customer has been acquired successfully the hard work has just begun. The customer will need to be held onto at least long enough to recoup any pre-sales expenditure(s) so as to avoid a net loss to the business. The total revenue generated on average by a customer prior to their turnover is what’s known in the SaaS industry as the Life Time Value (LTV). The basic formula for calculating the LTV of a customer is notated below.

Capture*ARPA = Average Revenue per Account

In addition to CaC and LTV the next big thing to pay close attention to is churn rate. This will help keep the business right-sized and strategically focused. For those unaware of the concept of churn; churn is what happens when a customer signs up for a service, becomes unsatisfied and leaves for the competition. Keeping the churn rate low (below 5% per year) is critical. This is because the business spends more capital acquiring a customer than initially brought in by the sale. When this occurs the business is effectively lending money the customer. So having a high churn rate means the business ends up bleeding money faster than it pulls it in.

Now that we have a general idea of how cloud financials work, the next logical question to ask next is what does all of this financial jargon have to do with engineering? The answer is simple, business and engineering efforts must be unified in resolve and oriented with the same strategic direction for a cloud based organization to succeed. As such the entire organization must be laser focused on the same strategic goal – “satisfying the customer through early delivery of valuable features”.

Cloud Prerequisite Requirements + Traditional Software Mindsets

Now that we have an understanding of the benefits of migrating to the cloud, as well as the financial considerations that are necessary to be successful, let’s look at some best practices and tips surrounding successful cloud software implementations. Before we begin it is probably best to first disregard our cherished copies of the 2005 best seller titled ‘How to create and deliver legacy software systems for dummies’. AND while we are at it let’s go ahead and get rid of cowboy mentalities, faulty business plans, lack of financial strategies, death marches, delivering software once every 3 years on CD’s, expensive mainframes, waterfall development, big bang releases, manual testing and painful integration cycles. That should be about the gist of what legacy software companies have been doing for the last 20 years. Now that we have a clean slate let’s look at some modern techniques and identify some tips to create and deliver cloud software effectively.

Scope the implementation properly

Creating a sustainable engineering team that can be wielded effectively is an absolute must have for any SaaS based software organization. The key word in the above statement is ‘sustainable’. To aid in the goal of creating a lean mean engineering team it is critical to reduce (where possible) the number of unique moving parts and erroneous features within the software system and simplify it down to something manageable (based on the number of employees you currently have).

To this end, creating something manageable may mean sacrificing business wants and settling for the critical business MUST haves that customers utilize the most. What good is a huge feature set with numerous bells and whistles that are partially completed? Even worse what good are bells and whistles if the engineering department that maintains those bells and whistles burns out and quits? Implementing a properly scoped cloud product in accordance to the number of employees can reduce turn over, assists in avoiding employee burn out, and keeps the engineering teams within acceptable work/life balance margins.


Tip #1: Ensure the feature scope of the software system is proportional to the number of employees & can developed/maintained at a consistent pace indefinitely. – Thank you Agile Manifesto


 

Go Agile or Go Home

The Agile manifesto and subsequent agile development practices have been around now for over a decade. Agile represents a shift in mindset, a cultural change and a way of thinking. It was created to help developers, managers and engineering resources create a manageable development process focused on short iteration cycles, increased release velocity and delivery of working software to customers rapidly.

Since its initial inception Agile has gained significant traction within the industry and is widely considered a best practice. When adopting agile development practices within an organization consider the following key points:

  • The definition of done: Done in an agile world means delivered to customers and generating revenue. NOT simply dev complete
  • Short iteration cycles (2 week sprints) with multiple builds per sprint can help keep the pipelines flowing. When adopting agile the smaller the commit size the easier it is to QA
  • Don’t make the sprint a death march.
  • Agile itself is a philosophy, the actual practical implementation at a shop can and should be altered to fit the shops unique needs; just don’t make it waterfall and call it agile.
  • Self organizing teams are key; add a sprinkle of autonomy and the team has everything they need to complete the iteration successfully (dev + test + delivery).

For additional information please consult the agile manifesto at:

http://agilemanifesto.org/


Tip #2: Leverage the Agile practice that works best for your organization but keep to the core tenants defined in the manifesto and use them as a guide.



Implement repeatable & efficient development processes

Industry pioneers Jez Humble and James shore introduced Continuous Delivery to the world. Continuous delivery aims to keep software in an always releasable state through the implementation of continuous integration, build pipelines, verification gauntlets and repeatable processes. When moving to the modern cloud Continuous Delivery is a virtual requirement. ‘CD’ may sound easy on the surface however it requires diligence, unified process standardization, team discipline, automation and trust all working together in concert. This makes CD a challenging but rewarding journey. Upon implementation of CD, an always releasable product can help reduce friction within an organization, reduce delays in market value, and alleviate silos between development, QA and the business. Upon achieving Continuous Delivery the business can strategically market, and reduce the risk of faulty software.

At the heart of Continuous Delivery is Continuous Integration (CI). Continuous Integration is a development best practice, which acts as a starting point for Continuous Delivery. Like CD, CI is not for the faint of heart. It requires a well indoctrinated set of self disciplined developers. CI is the practice of integrating code changes (merging) with the larger development team frequently (at best multiple times per day). This practice aims to communicate integrated code changes and provides insights into what others are working on. Committing code changes to a central mainline/master (a communication point) helps the team avoid risky merges, decreases isolated feature development, illustrates developer productivity, encourages modular development, and encourages team collaboration. In a CI environment each of the commits to the mainline are validated through an automated build and unit test system. The CI tool (Jenkins, TeamCity etc.) aims to automatically identify merge conflicts, logic collisions, and faulty merges. When issues are identified through automation, the best practice in CI is to fix it quickly or revert the change.


Tip #3: Adopting Continuous Integration & Continuous Delivery practices effectively is crucial for reliable and  efficient software development and delivery. When adopting CI and CD research these practices completely and do the due diligence necessary to be successful. Don’t just use the buzzwords – fully grasp each concept and see how to best apply them.


Once CI has been achieved Continuous Delivery can be implemented. Continuous Delivery extends CI by executing a set of automated verifications surrounding the potential viability of the software system. The acceptance automation executed in a Continuous Delivery system aims validate the following criteria:

  1. Can the software (including the current commit) be deployed onto a test environment?
  2. Does the software pass basic acceptance tests (automated)?
  3. Does the software contain regressions of any previously identified defects (automated)?

The result of a CD based development and delivery implementation is a software system that has quality built directly into the solution, a QA vigilant organization, and a software solution that is potentially releasable at any time.

Leverage Modular Architecture

Within the last few years there has been a lot of attention garnered by MicroServices (and rightfully so). Microservices may be relatively new within the modern cloud ecosystem but the concept of modularizing software architecture remains a tried and true best practice. This strategy has been leveraged effectively by some of the most notable cloud success stories and is worth the time and effort. For those unaware, Microservices are self encapsulated software components that can be independently developed, tested, deployed, and released. Microservices are generally deployed on solid infrastructure and interact through API’s or Message Queue communication layers. Multiple MicroServices work together in tandem to form a scalable cloud software solution. The result of implementing a microservice based solution is a highly scalable way to deliver valuable features to customers with minimal risk to the overall cloud solution. The illustration below describes an over-simplified Microservice software architecture.

microservices-proxy

Now that we have a basic understanding of Microservices covered, we can look at a couple of gotchas. One easily overlooked element of a Microservice is the data layer. This is to say the database system that a single microservice plugs into (if it requires one).  To achieve a complete microservice implementation it is equally important to modularize or encapsulate the data layer. This helps reduce complex database upgrades and avoids creating inadvertently creating a monolith.


Tip #4: Implement a component encapsulated or Micro-service architecture. This architecture can provide business value by decreasing time to market, by increasing deployment velocity.


When implementing a Micro-service strategy keep a close eye on how you will deliver it to customers in a repeatable and automated manner. This is best done through Continuous Delivery pipelines. Once the pipelines are in place, look for ways to achieve zero-downtime deployments with an emphasis on fast and efficient deployment tasks that can and will be exercised frequently. This will help the organization maximize delivery velocity and minimize the risk traditionally associated with software releases. Some zero downtime deployment strategies worth researching include:

  • Blue/Green deployments
  • Load-balanced deployments (drain un-drain)
  • Spinnaker (Netflix provided)

Adopting DevOps is a MUST

DevOps in many ways represents a new way of thinking about engineering, collaboration, delivery and business. It attempts to encapsulate a fundamental unified business direction and goal and not a specific team or individual. The term DevOps was formally introduced to the world in 2008 at the DevOps Days conference in Belgium. And while the word DevOps is relatively new in software engineering its roots can be traced back to the industrial revolution, Henry Ford and his quest for automotive success.

The DevOps word itself contains ‘developer’ and ‘operations’, but the reality is that DevOps scopes everything in between focuses on pipeline development, standards and providing value to the business. This concept goes back to the idea that when working towards releasing a cloud based software system, everyone in the business will need to be focused on the same goal and work to maximize efficiency. As such a DevOps journey should be a strategic business decision rather than a grass roots engineering endeavor.


Tip #5: To reach the cloud DevOps must be embraced by both the business and engineering as a unified strategic approach.


When implementing a DevOps based culture take a KaiZen approach. Identify inefficient processes first. Make those processes as efficient as possible, measure the results then automate them. Once development and delivery processes (from developer commit -> customers hands) has been automated revisit them and see if they can be made even more efficient. While working on automation pay extra attention to any manual processes that may still exist and automate those to the best of your ability (especially QA). This is important because anything manual will become a bottleneck later and a hindrance to getting features in front of customers fast. Some frameworks and best practices worth investigating include:

  • A/B Testing
  • Feature Toggles
  • CI->CD
  • Artifact Management (All the binaries managed properly)
[Total: 0    Average: 0/5]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">