One of the biggest mistakes we made was to take an existing legacy application and attempt to deploy it into a cloud infrastructure without any redesign. Thanks to CL9P for helping us unwind our processes and architecture to restore sanity to the project.
Defining a Cloud Reference Architecture
we believe the cloud is more about process than it is about technology
Building a Software Factory
Step 1: The Factory Floor
To create the factory floor, we need the ability to stamp out templates for our user base. These templates may just be an operating system or they could be a fully functional application development stack. The two primary technologies that simplify this capability are virtualization and containerization.
Step 2: Automation
The automation of a virtual infrastructure is what provides a development organization the capability to deliver a software factory. Automation is critical to streamlining the delivery of applications through a complex infrastructure layout.
Step 3: User Portal
Once the factory and automation have been defined, there are usually a number of different tools, jump servers, products, and databases that these tools interface with. To simplify the delivery of application workloads into the infrastructure, we need a simplified user portal to communicate with all of these products so we don’t need to train teams on all of the different tools nuances. This portal will link workloads together to allow for affinity based deployments to ensure proper scaling and performance of the application.
Step 4: Governance
Now that we have defined a streamlined application delivery platform, we can provide governance templates based on the automation that occurred. So when an application has gone through a set of automation gates, we will have approvals that will have been done automatically as well as manually to ensure we are monitoring all applications in the same way. Therefore, the recovery process will become automated when outages occur.
Step 5: Estimating
Leveraging our cloud reference architecture, operations and development teams work together to forecast and estimate future hardware requirements based on existing metrics for similar workloads through quotas. Because the infrastructure scales together based on a metric driven approach, we can deliver private and public cloud workloads in days for tasks that used to take months.
Step 6: Application Design
We mentor development teams in cloud technologies that allow applications to be designed for high availability, disaster recovery and failover. Developers are forced to design or fulfill contracts based on the current business requirements to meet the factory specifications. Project managers receive feedback on where the process needs improvement to ensure application delivery.
Step 7: Deployment and Testing
Testing is embedded in our methodology through the contracts defined by the development teams. Traditionally development artifacts are redeployed to a new set of infrastructure to allow the testing team to work isolation. We utilize the virtualization technology to snapshot our application at an instance in time to allow the development and testing teams to be working off the same artifact that will eventually be deployed to production.
Step 8: Scorecarding and Promotion
Application deployments are usually date driven. This means every other person needs to work to complete all of their tasks in this time frame leaving no flexibility when issues arise. This produces poor results and we have proven that a release train process works better in a factoring setting. At each stage of the development process a scorecard is delivered along with the application to ensure factory contracts are being met.
It really surprised us how quickly our project was in our development environment. We were able to find issues with our applications earlier which led to a better quality product for our customers. CL9P’s Software Factory overlay for traditional Agile Processes utilizing a Cloud Infrastructure reduced our development cost by over 35%.
Andrew KlingsmonDirector of Application Architecture
We have experience building and deploying applications to the cloud in the following verticals:
- Public Sector
With our vast experience we have come to the conclusion that all cloud applications fit into a reference business architecture that we use when working our customers. This is broken down into:
- Information Collection & Storage
- Integration Services
- User Interaction/Experience
Contact us to learn more.
- Red Hat
- Amazon Web Services
- Ruby on Rails
The Software Factory Process
Software factories have been around for about 15 years. Now that the cloud allows development teams to provision their own development environments, we can take advantage of a software factory approach. Just like a car moves through the plant, our application is executed in a set of standalone containers that can be moved as whole between environments. The only thing our dev/ops team needs to do is create a set of deployment templates that will provide application resources based on the context where it is going to run. We have manufacturing six sigma project managers that help to provide the rigor around the development process to ensure the end product is ready for delivery.
This is a very metric driven approach and we can provide insights about your team that will allow you to hire and manage more effectively. Some metrics we have used with past teams are:
- Bugs Per Lines Of Code Written
- Bugs Closed Per Sprint
- Performance Problems Per Class
- Lines of Code vs Bugs Created
- Closest Estimator
Contact us to learn more.
Cloud Nine Partners
121 Bryce Meadow Dr.
Holly Springs, NC 27540