Platform-as-a-Service (PaaS)


PaaS provides building blocks for you to develop and deploy your application without the complexity of licensing the software and buying infrastructure underneath it. PaaS also includes features that harden your application without having to write code for database backups, scalability, failover and disaster recovery, security patches, reliable messaging, networking, and much more.

An example of this sort of PaaS application can be found in the Microsoft Azure Cloud Platform. The solution includes your web application with a web front end and SQL Server for storage; this is integrated with CRM Online for customer data. It serves users on devices with various form factors connected via public Internet and through VPN. Figure 2-4 provides an example of a PaaS application built and deployed on Microsoft Azure platform.

The differentiating line between IaaS and PaaS is rapidly disappearing, with IaaS vendors providing more value-added services such as storage services, application host capabilities, and messaging systems in addition to a wide selection of OS versions. Similarly, predominantly PaaS solutions also leverage components of IaaS; as an example, in Figure 2-4, the solution includes SQL Server deployed as a virtual machine. PaaS services are subscription- or usage-based and billed on a monthly basis. For example, there may be a small monthly fee for the use of a load balancer or a database backup service.

Advantages of the PaaS are:
- Is a holistic or end-to-end platform with which to develop, deploy, and manage your application—no separate software licenses to procure or manage.
- Supports multitenant architecture where users from multiple organizations can use their partitioned space securely.
- Built-in scalability, including load balancing and failover, are significant benefits for you.
- Third-party solutions are available through the platform marketplaces to handle billing and subscription management via a library or RESTful API.
- Has ability to automate test and deployment services.
- Supports web-based user interface to manage the application.

And on the contrary, here are a few situations where PaaS may not be a good fit for your applications:
- If your application requires specialized hardware or software to perform its functions; PaaS platforms use commodity hardware.
- Where portability of the application is important—essentially your application will only run on the platform it was developed on. Essentially, you are locked in with a vendor.
- PaaS may also not be a good fit when customers have to migrate an existing application to the cloud, and when the effort to re-write the application does not offer any significant return on the investment. In this case, it's better to adopt a lift-and-shift approach and migrate the existing to IaaS virtual machines rather than create a PaaS solution.

PaaS is the most exciting and powerful cloud platform, and developers around the world view it as the go-to option for their new applications while existing applications continue on IaaS.

Taken from : Hardening Azure Applications

Infrastructure-as-a-Service (IaaS)


Infrastructure as a Service (IaaS) offers you software and hardware infrastructure components such as servers, operating systems, and network. Vendors will provide "templatized" or "pre-loaded" infrastructure with operating systems or database software; e.g., Windows Server 2008, Linux Ubuntu 14.10, or SQL Server 2012. You do not have to purchase servers or network equipment, license software, or rent data center space—instead you "rent" these resources from a vendor as a completely outsourced service.

While subscribing to this service, you are only required to manage your application, data, middleware, and runtime. The vendor manages your server—commonly delivered via virtualization and networking. The most significant advantage of this approach is that it allows you to avoid buying hardware, reduces project lead times, increases your ROI, and streamlines and automates scaling. For many project owners, IaaS is a first foray into the cloud world, especially scaling out to meet seasonal demand for processing capacity.

You should consider IaaS for the following workload situations:
- Demand is volatile or seasonal, such as on Black Monday.

- Time to market is critical, including time to provision and deploy.

- You have hard limits on budgets and capital expenditure.

- Your business has trial or temporary needs.

And on the contrary, here are a few situations in which IaaS may not be a good fit for your applications:

- Higher levels of scale and performance are required by your application than is supported.

- You have significantly high integration needs, especially with on-premises systems.

- Other cloud types, especially PaaS, may offer better ROI in the long term.

Taken from : Hardening Azure Applications

What's aaS?


What's aaS?

Let's backtrack our conversation a bit and use a common concept, a pizza dinner, as a metaphor by which to make sense of these acronyms and, more importantly, the cloud.

You are in charge of organizing a pizza party for your team—your four main options to feed your team are:

1. Make a pizza from scratch—the self-service approach. You are responsible for buying all the ingredients, making the dough, and making all the arrangements to seat and serve the team. It's lots of work, but your pizza will be exactly the way you want it to be.

2. Use the take and bake service—where you purchase the pizza base with toppings and bake it fresh in time for your guests. It's less work, and you only have control over the crispiness and freshness of the pizza.

3. Order from a pizza delivery service—just arrange the table and buy beer. It's quite convenient; however, there are fewer options for you to customize.

4. Take your team to a dine-in restaurant—just pay the bill. You have little control over the ingredients or cooking style, although it's very convenient. Every aspect of the experience is managed by the vendor/restaurateur.

In each option, you and your team have pizza for dinner; however, each option requires varying degrees of effort on the part of you and your vendor. In the scratch option, you do all the work, and in the dine-in option, the vendor does all the work for you.

Platform Types
- Cloud platforms provide you with computing/information technology resources quickly and with much lower total cost of ownership as compared to a self hosted platform. You can think of the resources as layers that build on each other—applications build on a platform that is hosted on servers and integrated with other servers via networking, and a distributed operation system governs the data center and its resources. The operation system governs the allocation and de-allocation of computing resources, machine updates, provisioning, monitoring, and user onboarding.

- Infrastructure resources: networking hardware/connectivity (e.g., VPN), servers, and operating systems.

- Platform software: storage, monitoring, app host, and integration.

- Application software: logic, schema objects, and business rules.

The Hyped


The next category includes ideas that may have value but are unlikely to make a significant difference in matters that count: productivity of the software process and quality of software products. Under this heading we may include:

- Pair programming, hyped beyond reason. As a practice to be applied occasionally, pair programming is a useful addition to the programming team's bag of tricks. But there is no credible evidence that it provides major improvements to the programming process or that it is better than classical techniques such as code reviews, and no reason to impose it as the sole mode of development.

- Open-space working arrangements. There is no single formula for the layout of a working environment. What we do know is that it is essential to provide simple, obvious opportunities for informal communication. Beyond that, many office setups are possible which will not endanger a team's success. (A related point appears, however, under the "good" ideas of the next section: avoiding distributed development.)

- Self-organizing teams. A few teams are competent and experienced enough to man-age themselves, like a conductor-less orchestra. Most are not. Each situation calls for its own organizational solutions and there is no reason to impose a single scheme on the entire industry.

- Working at a sustainable pace. All great advice; death marches are not a good management practice. But advice can only be wishful here; these matters are determined by economic and organizational pressures more than by good intentions. They are not specific to the programming world: like a company that is responding to a Request For Proposals, a researcher who is facing a conference submission deadline will work through the night to meet it. The most software methodologists can do is to argue that such practices should remain the exception.

- Producing minimal functionality. It is always a good habit to question whether pro-posed features are really needed. But usually they get introduced for a reason: some important customer wants them. It is easy to rail against bloat or heap scorn on monster software (Microsoft Word and Adobe Acrobat are common targets), but try to remove any functionality and brace for the screams of the outraged users.

- Planning game, planning poker. These are interesting techniques to help estimate in advance the cost and time of development activities, but they cannot be a substitute for more scientific approaches. In particular, they are open to the danger of intimidation by the crowd; the voice of the expert risks being smothered by the chorus of novices.

- Members and observers. In project meetings, the views of the people most seriously involved matter most. This trivial observation does not deserve the amount of attention that the agile canon devotes to the distinction between "pigs" and "chickens".

- Collective code ownership. The policy governing who is permitted to change various parts of the code is a delicate decision for each project; it depends on the nature of the team and many other considerations. It is pointless to prescribe a universal solution.

- Cross-functional teams. It is a good idea to encourage developers to gain broad competence and to avoid dividing the projects into narrow kingdoms of expertise each under the control of one person. Beyond this general advice, there is little a method can change here to the obvious observation that special areas require special skills. If one of your developers is a database expert and another is a concurrency expert, you will not ask the first, if you have a choice, to resolve a tricky deadlock issue, or the second to optimize queries. This observation is another reason why the agile scheduling policy of picking the highest-business-value task in the pipeline is simplistic and potentially harmful.

Taken from : Agile!: The Good, the Hype and the Ugly

The Bad and the Ugly


We start with the worst in the agile approach: ideas that damage the software process.

Deprecation of Upfront Tasks
The prize undisputedly goes to the deprecation of "upfront" activities, in particular upfront requirements and upfront design.
Agile criticism of "Big Upfront Anything" includes some perceptive comments. It is true that one cannot fully comprehend requirements before the development of the system; that requirements will change; that the architecture will have to be improved as implementation proceeds. Those observations express some of the fundamental difficulties of software engineering, and the futility of trying to define everything at the beginning.

There is, however, no argument for shunning the normal engineering practice — the practice, in fact, of any rational endeavor — of studying a problem before attempting to solve it, and of defining the architecture of the solution before embarking on the details. The alternative proposed by agile methods is an ad hoc approach: identify some functionality, build it, assess and correct the result, repeat. It is no substitute for serious requirements and design.

Iterative development is great. Trying out ideas on a small scale before you make final decisions is great. Treating requirements as a living, changeable product is great. Reassessing design decisions on the basis of results is great. Insisting on regular deliveries (once the basic structure is in place) is great. Refactoring is listed at the end of this chapter as one of the significant contributions of agile methods. None of these ideas justifies forsaking the initial tasks of analysis and design.

In other cases we can see the pros and cons of agile ideas. Here there is no place for equivocating: neglecting these upfront steps, as agile authors advocate, is guaranteed to harm your development.

User Stories as A Basis for Requirements
User stories play a useful role as ways to check the completeness of requirements, but to use them as the basic form of requirements means forsaking abstraction. In addition, they ignore the critical Jack-son-Zave distinction between the machine being built and the domain that constrains it.

The resulting systems are narrowly geared to the specific user stories that have been identified; they often do not apply to other uses; and they are hard to adapt to more general requirements.
User stories are no substitute for a system requirements effort aimed at defining the key abstractions and the associated operations (the domain model) and clearly separating machine and domain properties.

Feature-Based Development and Ignorance of Dependencies
A core idea of agile methods is that you can treat software development as a sequence of implementations of individual features, selected at each step on the basis of their business value. It would be great if such an approach were applicable, but it exists only in a land of make-believe. Difficult projects do not lend themselves to this scheme: they require foundational work (building core architectural elements, such as a communication or persistence layer) which extend across features; and the features interact through dependencies, causing complexity of the "multiplicative" kind.

Rejection of Dependency Tracking Tools
The potential complexity of feature interactions requires a careful analysis of task dependencies; projects can skip this analysis only at their own risk. The advice to stay away from Gantt charts and dependency-management tools is not only naïve but detrimental. Such tools are not a panacea for project management but have proved their value over several decades of use. They can help agile projects just as well; dogmatic rejection of useful tools is a self-inflicted wound.

Rejection of Traditional Manager Tasks
The self -organizing teams promoted by agile methods, with no manager having the traditional duty of assigning tasks, are the best solution for a few teams, and are inappropriate for many others. The picture of the manager as an incompetent control freak is a caricature. Many software projects have been brought to completion, and many projects on the brink of failure have been rescued, through the talents of a strong manager. Imposing a single management scheme on everyone is arrogant.

Rejection of Upfront Generalization
Agilist rightly note that the primary responsibility of a project is to deliver working software to its customers, and that too much early concern for extendibility (ease of change) and reusability (applicability to future projects) can hinder that goal, especially since it is not always clear initially in what direction the software will be extended and which parts will need reuse. But these observations are not a reason to reject the concept of generalization altogether. We have seen that such an attitude directly contradicts the professed agile principle of "welcoming change". Good software developers do not wait for change to happen: they plan for it by designing flexible architectures and solving more than the problem of the moment.

Embedded Customer
The XP idea of a customer representative embedded in the development team does not work well in practice, for reasons explained in an earlier discussion. The Scrum notion of a product owner, however, figures below in the list of excellent ideas.

Coach as a Separate Role
The Scrum idea of a dedicated Scrum Master is good for Scrum, but not appropriate for most projects. Good development requires not just talkers but doers.

Test-Driven Development
Test-first development, and the requirement of associating a test with every piece of functionality, appear in the lists of good and excellent ideas below. So does refactoring.
Test-driven development is another matter. A software process defined as the repeated execution of the basic steps of TDD — write a test, fix the code to pass the test, refactor if needed — cannot be taken seriously. With such an approach one is limited to tunnel vision, focused on the latest test. An effective process requires a high-level perspective, considering the entire system.

While test-driven development is extensively discussed in the literature, industry has made its choice: it is not broadly practicing this technique. (On the other hand, many companies have adopted user stories. One may only hope that they will realize that replacing requirements by user stories is the same as replacing specifications by tests.)

Deprecation of Documents
Agile criticism of document-heavy processes that produce little real customer benefit is right on target for some segments of the industry — although in some cases, such as missioncritical systems, little can be done about the situation since the documents are legally required by certifying agencies. (And not just out of bureaucratic inertia. Even the most enthusiastic agilist might feel, when flying to the next agile conference, that it was not such a bad idea after all — not total "waste"— to assess the plane's software against a whole pile of certification standards.)

Outside of specific industries with high regulatory requirements, a strong case exists for lightening up the document infrastructure. It is true, as agilists emphasize, that "design" in software is not as remote from production (implementation) in other engineering fields. Modern programming languages help, because they make it possible to include some of the traditional design in the code itself. (Some of my own work has addressed this issue.) None of these observations, however, can justify the deprecation of upfront plans and documents. Software engineering is engineering, or should be, and sorely needs the benefits of a careful predictive approach, as well as the supporting documents.

Taken from : Agile!: The Good, the Hype and the Ugly

Iteration Planning


A number of agile practices take the form of regular meetings. We have already seen the "daily meeting", but there are others, codified in particular by Scrum.

At the start of an iteration (a sprint in Scrum) there should be a meeting to plan that iteration. The meeting should produce three main outcomes:

1. An iteration goal, describing what the team plans to achieve in the iteration, concisely — a sentence or two — and in terms understandable by ordinary stakeholders. A typical example (assuming a compiler project) is: implement the new functional-language extensions.

2. An iteration backlog: the list of tasks to be implemented. This outcome is primarily for the internal benefit of the team.

3. The list of acceptance criteria for each task.

Conspicuously absent from these goals are: the assignment of tasks to individual team members, which will be done at the "last possible moment" according to the rule of cross- functionality; and a list of testing tasks, since testing is done continuously as part of the implementation of user stories, not as a separate activity.

The meeting is primarily reserved for the team and the product owner. As the team will be responsible for implementing the backlog in the allotted time, the result represents a commitment on its part, normally ruling out the participation of observers.

The definition of tasks (outcome 2 above) is a two-step process: select user stories from the backlog for the entire product; then, decompose each of them into tasks.

The process also requires estimating the cost of each task. This is where techniques such as the planning game and planning poker, discussed earlier in this chapter, come into play. Because the team is in the best position to size up tasks that it will have to implement, the product owner may at times be asked to leave the meeting while this estimation is in progress. Disagreements may imply repetitive application of the process.

To avoid endless discussions, the meeting has a time limit, generally a single day (eight hours), sometimes split into two parts, one for selecting user stories and the other for decomposing them into tasks.

Taken from : Agile!: The Good, the Hype and the Ugly

Subscribe to Computing Tech

Enter your email address:

Delivered by FeedBurner

Alltop, all the top stories
All Malaysian Bloggers Project
Add to Technorati Favorites Top Blogs
Computer Blogs - BlogCatalog Blog Directory blogarama - the blog directory Top Computers blogs Software TopOfBlogs Information Technology, SEO Technology