I've found interesting post where author summarize technologies used for most large-scale web sites
четвер, 17 листопада 2011 р.
вівторок, 1 листопада 2011 р.
Utah SaaS Workshop (Update)
As I promised, in this post I am publishing some materials about Utah workshop. Follow the link you could collect general information about workshop and see presentation what Russ provide. In additional to this I would like share some overview:
1. Personal communication is more valuable and help talk about details and suggest better approaches than general questions what come up during presentation and panel session
2. DB is the major paint for every one
3. Sometime even simple idea what is lay on top may be useful for clients
4. Abstract presentation may not be attractive for the participants – next time we may concentrate on the discussion solution for different problem solving from technical stand point and business impact.
5. Grate event :) and cool participants :):)
1. Personal communication is more valuable and help talk about details and suggest better approaches than general questions what come up during presentation and panel session
2. DB is the major paint for every one
3. Sometime even simple idea what is lay on top may be useful for clients
4. Abstract presentation may not be attractive for the participants – next time we may concentrate on the discussion solution for different problem solving from technical stand point and business impact.
5. Grate event :) and cool participants :):)
вівторок, 18 жовтня 2011 р.
Utah SaaS Workshop
This Tuesday, I’ve performing the Q&A session in SoftServe SaaS workshop in Utah. It was the first time when I was as front man and answer on questions related to the SaaS architecture and solutions. Good experience for me, meet new interesting people and of course observe what is an interest of the audience. I will post more details later but as a short summary – it was grate day and we (me, Serge – Director of Architecture Group and Russ – VP of SaaS) successfully hold this event.
середа, 27 квітня 2011 р.
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.
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.
вівторок, 26 квітня 2011 р.
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
to see video go
http://www.youtube.com/watch?v=q3RrsdnWWsI&feature=youtu.be&a
понеділок, 25 квітня 2011 р.
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.
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
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
Підписатися на:
Дописи (Atom)