Main reasons for Choosing Scale-Out

1. Continuous Availability/Redundancy: You should assume that failure is inevitable, and therefore having one big system is going to lead to a single point of failure. In addition, the recovery process is going to be fairly long which could lead to a extended down-time.

2. Cost/Performance Flexibility: As hardware costs and capacity tend to vary quickly over time, you want to have the flexibility to choose the optimal configuration setup at any given time or opportunity to optimize cost/performance. If your system is designed for scale-up only, then you are pretty much locked into a certain minimum price driven by the hardware that you are using. This could be even more relevant if you are an ISV or SaaS provider, where the cost margin of your application is critical to your business. In a competitive situation, the lack of flexibility could actually kill your business.

3. Continuous Upgrades: Building an application as one big unit is going to make it harder or even impossible to add or change pieces of code individually, without bringing the entire system down. In these cases it is probably better to decouple your application into concrete sets of services that can be maintained independently.

4. Geographical Distribution: There are cases where an application needs to be spread across data centers or geographical location to handle disaster recovery scenarios or to reduce geographical latency. In these cases you are forced to distribute your application and the option of putting it in a single box doesn’t exist.

Softserve SaaS Dev Kit

In the youtube is video about my company SaaS initiative - I am happy that i put some effort in this initiative in the early beginning
to see video go
http://www.youtube.com/watch?v=q3RrsdnWWsI&feature=youtu.be&a

Delivery Models

Found summary of the cloud service classification like Delivery models and Deployment models see previous post

Cloud services delivery can be broadly classified into three models. This is commonly called as SPI model.

1. Software as a Service (SaaS): Software applications delivered from the cloud using multi-tenancy and accessible by various devices using a web browser. The vendor controls the entire stack from hardware to applications with users having the control over their data.

2. Platform as a Service (PaaS): Application platform that completely abstracts all the complexities of the underlying infrastructure and delivered as a service for the users to deploy applications that can be accessed over the network. There are striations inside the PaaS itself with IDE as a service on one end to pure middleware as a service on the other end. For the sake of simplicity, we stick to the SPI model and consider various types of platform services within the PaaS categorization itself. The provider controls everything from hardware till the platform layer and users have complete control over their applications.

3. Infrastructure as a Service (IaaS): Raw compute power and storage offered as a service with a metered billing where users can deploy and run different software from operating systems to platforms to applications. Compared to PaaS, the abstraction is taken to a lower level in the infrastructure and users get more control over the configuration of platform itself. The provider manages the hardware and other infrastructure needed to run the virtual machines and the users get to control everything from OS to applications.

Deployment Models

One of the most important model in the cloud services is – delivery models

1. Public Clouds: Public Clouds, also called as the real cloud by some purists, is the availability of cloud infrastructure to general public and accessible through the Internet. The infrastructure is owned by 3rd party service provider and is present outside the firewall of organizations using it. Multi-tenancy is the key differentiating factor here, which results in what we now call as Cloud Economics.

2. Private Clouds: Private Clouds are cloud infrastructure operated solely for an organization either by the IT of the organization or 3rd party. The infrastructure can be present inside of the organization’s firewall or operated in a 3rd party datacenter. Cloud economics will not be in play here but organizations can take advantage of other cloud characteristics like better utilization and elasticity.

3. Community Clouds: Community Clouds are cloud infrastructure shared by different organizations that supports specific community or verticals with shared needs. One or more of the participating organizations or a 3rd party may manage the infrastructure. The infrastructure can be present either inside the firewall or with 3rd party datacenters.

4. Hybrid Clouds: Hybrid Clouds are cloud infrastructure made up of two or more clouds (public, private, community) with one of them leveraged from a public cloud provider. These are independent cloud deployments that are bound together by standardized or proprietary technology that enables data and application portability. Usually, enterprises with a private cloud infrastructure tap into public clouds to push certain non-critical workloads in order to meet their sudden resource requirements

10 main requirements for SaaS/Cloud applications

Find interesting post regarding 10 main requirements for SaaS/Cloud applications. Below is short notes:

1. True Multi-tenancy. Multi-tenancy is the only proven SaaS delivery architecture that eliminates many of the problems created by the traditional software licensing and upgrade model—period.
2. Regularly Delivered, Vendor-Managed Updates. A cloud application is a single version of software that is regularly updated, often several times a year, for all customers, at no additional charge.
3. Seamless Integration On Demand. Cloud applications should be built from the ground up to lower the cost, time, and risk of integrating them with existing on-premise and on-demand applications.
4. Business-Driven Configurability. Cloud apps should be configurable, so your IT organization is freed from costly customizations (the most over-rated virtue of traditional software, in my opinion), and businesspeople can configure processes that meet the specific needs of the organization. That said, you should be able to choose from among multiple types of configurations.
5. World-Class Data Center and Security. A cloud application provider should be able to offer world-class security and data privacy better than its customers can do on their own, and at no additional cost. That includes physical, network, application, and data-level security, as well as full back-up and disaster recovery. The provider should be compliant with security-oriented laws and auditing programs, including Safe Harbor, ISO 27001, and SAS70 Type II.
6. A High-Performance, Sustainable IT Infrastructure. The provider should maintain a high-performance IT infrastructure, which includes the data centers and databases, operating systems, networks, and storage systems used to run cloud applications and manage customer data.
7. Predictable Total Cost of Ownership Model. There should be no surprise costs with cloud applications. Implementation costs should be predictable, subscription-based pricing should have no hidden fees, and no investments should be required for hardware and software license fees.
8. Faster Deployment. Since cloud applications don’t require investments and installation of hardware and software, you should be able to get them running and productive in a fraction of the time compared with on-premise software.
9. Control. Cloud applications should allow you complete control of your organization’s data, even though it is located off premise. Nothing should hinder your ability to import, export, purge, and archive data to and from the application without having to first contact the SaaS vendor.
10. Liberation from Non-Strategic IT Issues. Cloud applications should free teams from time and energy spent on non-strategic, back-office IT operations and software coding. Today and into the future, the most highly valued CIOs—the ones that become heroes to the business—are those who are closely aligned with strategic business initiatives and drive the IT projects that support those initiatives.

Original post is here

Large-Scale Agile Design & Architecture: Ways of Working

This week I’ve read topic about architecture on the InfoQ - Large-Scale Agile Design & Architecture: Ways of Working
There is a lot of suggestions about Agile architecture and thoughts around Astronaut Architect, Power Point Architects and etc.
For some reasons such architects are really does not bring any benefits for the projects inside the big company, but from other side if the hierarchy with in company properly organized they will bring a lot of the benefits. Just of example, some of the main role of the PowerPoint architect to talk with managers or customers about why we need refactoring, why we need change something and what goal should be accomplished. The example provided by author regarding the selecting processor just confirm that company does not have good communications inside the development.

Also author is talking that real architecture is the source code and that is true, but when project starts and only limited people involved in to the initial stage the role of the architect and having initial architecture on the paper is really important. Architect and paper architecture are main information about what we are really building and used for teach developers about components they will work on. Architect should keep in mind all components and he is the primary decision maker for any cross components aspects. When team start coding, his role transforms to the Master gardener, who is looking around, check implementation, code quality, and how architecture grows.

However many important practices was introduced in this topic that may really help to build architecture. My favorite is Design Workshop. If you have team with preliminary same level this session will help you to establish the common vision for the development and help to identify holes in the architecture in the latest stages. For one of my project where we had star team we doing workshops very often and it helps us to deliver feature in time with maximum features and this code still alive in the production.

Also mentioned standard approaches about decoupling components, abstraction from specific realization, TDD, and other practice but this is an general things what everyone should.

The last thing I would like to emphasize regarding architecture in the Agile – you like architect should control implementation because due focus on the features development team has temptation implement something quickly and then left it as is for the final release. This situation like what author mentioned about garden. So keep your ayes opened, review code on regular basis to avoid surprise in the end.

Small changes vs rewrite components

Just wake up after long fly, Baggage is lost in the Chicago so have a fun yesterday evening. During the fly have many time to thinking about how to transform the legacy application to new technology and what is the best approach.
I hear a lot of time when people telling me if we have 24 million dollars and 3 year we may rewrite application but now we didn’t have big budget and time is limited.

Small changes vs rewrite components
In life exists two approaches how to move application to new technology
1. Horizontal – when rewrites one of the layer (UI, Business, DAL, …)
2. Vertical – when application splits into logical modules and rewrite everything starting from DB and finishing UI

The first approach is good when you have good layers divided by interface and this is approach is good for the End User since usability experience will be changed at once and will not have transition period.

Second approach mostly used to resolve two issues – scalability and improve application architecture. It allow to rethink about existing functionality, optimize code, optimize UI so general improvement of application.

So what to approach select when budget and time limitation occurs?
Per my understanding and feeling I would suggest the following
1. Define long term goal
2. Analyze performance and other most critical issues
3. Predict in 3 – 5 years how your customers will grow
4. Analyze available resources

Only after this make any decisions

For example if you have event now some troubles with scalability and your goal move to SaaS I would strongly suggest using vertical approach
If you comfortable with scalability right now and didn’t expect any significant changes in nearest future, architecture is quite good I would suggest use horizontal approach.

As the last thought don’t forget about approach 20 X 80 when you change 20 % of functionality what cover 80 % of client needs may be this is a good start for doing new application from scratch …