It goes without saying that planning, engineering, and profiting from a cloud-oriented software solution is an ambitious undertaking. While many startups and enterprises alike actively pursue 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 to decipher the best practices that have aided many businesses in succeeding where others failed.
Basic Cloud/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. Albeit uninteresting, understanding the general finance aspects of SaaS can help us better understand the tasks required and grasp the importance of the 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 will need to be made. The sales and marketing expenditures required to gain a customer combined are commonly referred to as the ‘Cost to Aquire’ (CaC).
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.
*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 to 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 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 lazer focused on the same strategic goal: “satisfying the customer through early delivery of valuable features.”
Pre-Cloud 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 three 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 be 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.
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: Leverage CI and CD to deliver features effectively an research these practices fully before using them as CI is not the same as CD and both take a specific mindset to be achieved.
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:
- Can the software (including the current commit) be deployed onto a test environment?
- Does the software pass basic acceptance tests (automated)?
- 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 APIs 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.
Image Source: http://blog.arungupta.me/microservice-design-patterns/
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 microservice architecture. This architecture can provide business value by decreasing time to market, by increasing deployment velocity.
When implementing a microservice 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 undrain)
- 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 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
- Artifact Management (All the binaries managed properly)
Reaching for the cloud is totally achievable, however it's not for the feint of heart. It takes due dilligence, research, and a more modern way of managing development, QA, and release systems. Within the cloud-based arena trusting the people, processes and the teams in charge with the products is an absolute requirement. Without trust we tend to create gates, bottlenecks and boundries of which are detrimental to a cloud-based business. Fail fast, and recover even faster and the clouds can be within reach.