Best Practices and Methodologies to building and designing Cloud Architectures

Putting the business needs and goals 1st in Designing Private and Hybrid Cloud Architectures

V1.0

Presented by Dean DelamontDecember 2016

A guide to Best Practices and Methodologies to building and designing Cloud Architectures

Copyright 2016 - Dean Delamont

Identify the business goals and objectivesStep 1: Discover what the business goals are and objectives that your trying to solve. Once understood you can start to work on a blue print design. Objectives may include:o The need for daily buildso The need to maintain HA and QoSo The need to push builds and updates to multiple sites o The need to push small incremental updates in small sprints to a customer

site without complications resulting from a monolithic or tightly coupled solution that has cross coupling dependencies.

o The need to automate your software delivery mechanisms through Continuous Integration and Development (CI-CD) pipelines.

Note it is important to consider here not just the functional requirements but the non-functional aspects in identifying the business goals and objectives as well as in designing your Cloud Architecture as much as the functional ones. One example of a non-functional requirement could be that your solutions Service Availability needs to be guaranteed to 99.99 availability as per the business commitments in the SLA.

Warning: Its very easy to ignore or not to consider these NFR aspects, however the implications could be significant to your businesses success in migrating or deploying its software solutions in the cloud as such I do recommend you consider the benefits of this to your business.


Identify the business goals and objectivesStep 1: Discover what the business goals and objectives are by consulting with key stakeholders – Product Directors, Product Managers, Product Owners, Operators, Executive Sponsor etc.

Consider in Design and

Cloud Architecture

Capture Business & Technical ObjectivesCapture Business goals

Stakeholder Consultation Phase

TIP: You can use JIRA or other tools to collect the business objectives and goals.

Note: as a business its very important to involve all stakeholders in this process and not to just focuson the technical objectives inviting just your development team and architects since throwing something together based solely on the technical objectives will undoubtedly result in failure for your business. It is recommended therefore to invest time in capturing the full business goals and objectives before setting forth in designing your cloud architecture. Copyright 2016 - Dean Delamont

Identify how you can introduce efficienciesStep 2: When designing Cloud architectures it is recommended to consider how you can not just satisfy the basic business needs for say daily builds, but how you can introduce efficiencies to help for example lower the cost of your Cloud implementation.

For example you may want to consider:o Making the services within your Cloud Self-serviceable o How you can enable the automation of functions more efficiently in your

cloud such as providing auto-scaling on-demando API re-use. Enabling the repeatable and reuse of existing APIs such as for

DBaaS rather than building your own custom implementation.

The above examples are just to illustrate that through considering efficiencies and NFRs like the need to have re-usable APIs this can help not just achieve your organisations business goals and objectives but in fact lower your OPEX costs improving your businesses operating profitability.

Note: Its easy to focus on just the functional needs or shrug your shoulders on this thinking I don’t have time to look into all of these aspects I just need to get on, but considering these aspects will help you build a better more re-usable and sustainable cloud architecture for your company which in the long run could mean the difference in profit or loss.


Before putting hand to paper – experiment Step 3: Don’t be tempted to just produce a blue print document to later find out you didn’t consider key aspects which cost your business significantly in loss of reputation or profitability, go out and try it yourself.

As a Cloud Architect its not enough to put pen to paper you need to roll up you sleeves and experiment by installing your own OpenStack Cloud using DevStack for example to get started and then try to install the individual open stack services to try out your theories. If you don’t do this then you should be prepared for surprises later as simply reading the OpenStack documentation or designing architectures on the white board with others is really not enough to be sure that what you have designed will satisfy the business goals and objectives.

TIP: I recommend if your not familiar with OpenStack go on a foundational training course, team up and collaborate with others on Dev Ops initiatives working on specific areas of cloud. You may be surprised what you learn and the value this then gives you back in your system architecture designs for your cloud infrastructure and solution deployment architectures.


Cloud Architecture

iterative design method

The design cycle – design, experiment, discover, refine Step 4: The design cycle: Work iteratively in an Agile Dev Ops methodology.

Experiment

Design

Discover

Publish findingsand research

AnalyseResults and findings.

Optimise and refine

Note through this cycle of working you are continually optimising and refining you design for your cloud solution until all the business needs, business objects and technical objectives are satisfied. TIP: User an Agile Dev Ops and iterative approach. As you learn document your findings in a wiki that later you and others can benefit from in the design of your cloud solutions. Also throughout this process consider the benefits of what you have learnt to other parts of your organisation or the wider open source community where I encourage you to share your findings with others. Use the opportunity also to train others and increase their skills.

Deploy, operate, test design assumptions and theories

Validate findings


The design circle – a process of continuous improvementAs you go through the design cycle it is recommended that you should;

Deploy, operate and test your design – capturing your findings with your team

Analyse and measure the findings against defined metrics – here you are measuring to what degree were the business goals and objectives met.

Validate findings are not a one off and if the business original goals and objectives are meet

Review your design continually refining and optimising the design where your findings show the business objectives and goals are not meet

Where your findings show failure to meet the business goals and objectives you should go back through the process of improvement and refine your design, experiment with alternative approaches until based on your findings the business goals and objectives have been satisfied.

TIP: Collaborate with your team and others in operating the system to validate findings, review findings, discuss alternative solutions/technologies to help refine your system design. A highly effective Cloud Architect or Cloud Deployment Architecture technical lead is one that works with the developers and engineers or other system architects collaborating in design lead initiatives in a Dev Ops approach.


Keeping the end goals in mindAs you go through the design cycle working iteratively consider the need for:

Repeatable re-use A standardised Cloud Framework for developing and delivering your software

solutions to help reduce the complexity faced by your organisations different product teams

Best Practices Ease of adoption by your customers – its no good if 50% of your customer

are using for example AWS public clouds and you design your solution to solely work on Azure.

Alternative technologies and solutions weighing up the cost and non-functional benefits considering the business needs for cost efficiency, scalability etc.

Make sure also to reflect back on the original business goals and objectives to validate that your design is meeting all of your business needs throughout the process.

Lastly don’t be afraid to fail during your design cycles as through experimenting we learn how to avoid mistakes that could otherwise be very costly plus we make valuable discoveries that lead to knew opportunities in leveraging new technologies in new ways. Failing is just a way to learn and improve your designs.


ConclusionThroughout my many years experience in working in Non functional requirements and designing cloud deployment architectures I have learnt that when it comes to be successful in designing a well thought through Cloud Architecture, you must consider the Business needs ahead of the technical needs.

I have seen many times a system architect ignore or not realise they need to consider the business needs when designing cloud architectures for which the consequence to the business could be significant in terms of irrevocable damage in reputation or in spiraling costs impacting negatively a businesses operating margins or EBITDA. Consider the business need to meet its SLAs for 99.99% availability, a system that has say only 67% availability may have irrevocable damage on a businesses reputation. If you consider also other non-functional aspects like legal ramifications for data protection or commercial risk exposure of running a SaaS offering in which if no one can quantify the actual TCO of your solution where the architecture was designed with no consideration of the cost needs for the business or its pricing model then your running a high risk business which could succeed or fail in its cloud endeavors. Remember the cloud has shaped economies causing the top FTSE 100 companies in the UK alone to fail or succeed.

I encourage you to take up some of the suggested best practice and methodologies in this presentation that I have produced from real life practical experience where I lead many design initiatives on cloud architectures working in the same Dev Ops Agile methodology as detailed in this presentation. This helped me to better shape my organisations solutions at the time for Cloud as well as resulted in some improvements to OpenStack as such you can expect positive business impacting results from this approach. Copyright 2016 - Dean Delamont

Recommendations for Cloud System ArchitectsFor anyone reading this that is interested in adopting the recommended methodology and best practices in cloud design I would recommend if you don’t have any hands on experience in OpenStack or Cloud OS’s iI suggest to take an hands on course in:

- OpenStack basics covering use of Heat, Horizon (Dashboard) etc. - Orchestration using Heat Scripts – you don’t need to be an expert but having a good

understanding of how the heat scripts are used is beneficial. - Networking – how to work with Neutron or other Network Architecture approaches like

Provider Network. - Storage – This is a very intellectually stimulating way to learn about Cloud Storage

technologies. I recommend a course in Ceph or Swift.

There are lots of other OpenStack course you can do which I am sure you can find. I suggest also to pair up with others on DevOps initiatives since this is a great way to learn.

I hope this presentation is useful to you and I wish you the best in your Cloud Design endeavors.


Thanks for listening!

V1.0

Presented by Dean DelamontDecember 2016

A guide to Best Practices and Methodologies to building and designing Cloud Architectures

Putting the business needs and goals 1st in Designing

Private and Hybrid Cloud Architectures

Part of a series of presentations on how to achieve efficiencies in business from the cloud.

Next Time:

Achieving Agile and Scalable Infrastructures through Cloud Platforms

V1.0

Dean DelamontDecember 2016

Documents

Best Practices and Methodologies to building and designing Cloud Architectures