Microsoft Cloud Development: Patterns & Practices

Cloud Development

patterns & practices Developer Center

Summary

How do you build applications to be scalable and have high availability? Along with developing the applications, you must also have an infrastructure that can support them. You may need to add servers or increase the capacities of existing ones, have redundant hardware, add logic to the application to handle distributed computing, and add logic for failovers. You have to do this even if an application is in high demand for only short periods of time.

The cloud offers a solution to this dilemma. The cloud is made up of interconnected servers located in various data centers. However, you see what appears to be a centralized location that someone else hosts and manages. By shifting the responsibility of maintaining an infrastructure to someone else, you’re free to concentrate on what matters most: the application.

Active Releases

Community

This guidance, like many patterns & practices deliverables, is associated with a community site. On the Microsoft Azure Guidance Community and Microsoft Azure Media Services Guidance, you can post questions, provide feedback, or connect with other users for sharing ideas. Community members can also help Microsoft plan and test future offerings and download additional content such as extensions and training material.

Using Background Jobs in Enterprise Applications

Overview

Many types of applications require background tasks that run independently of the user interface (UI). Examples include batch jobs, intensive processing tasks, and long running processes such as workflows. Background jobs can be executed without requiring user interaction; the application can start the job and then continue to process interactive requests from users. This can help to minimize the load on the application UI, which can improve availability and reduce interactive response times.

For example, if an application is required to generate thumbnails of images uploaded by users, it can do this as a background job and save the thumbnail to storage when complete without the user needing to wait for the process to complete. In the same way, a user placing an order can initiate a background workflow that processes the order, while the UI allows the user to continue browsing the web app. When the background job is complete, it can update the stored orders data and send an email to the user confirming the order.

When considering whether to implement a task as a background job, the main criteria is whether the task can run without user interaction and without the UI needing to wait for the job to complete. Tasks that require the user or the UI to wait while they are completed may not be appropriate as background jobs.

Types of background jobs

Background jobs typically have one or more of the following characteristics:

  • CPU intensive jobs such as mathematical calculations, structural model analysis, and more.
  • I/O intensive jobs such as executing a series of storage transactions or indexing files.
  • Batch jobs such as nightly data updates or scheduled processing.
  • Long running workflows such as order fulfillment or provisioning services and systems.
  • Sensitive data processing where the task is handed off to a more secure location for processing. For example, you may not want to process sensitive data within a web app, and instead use a pattern such as Gatekeeper to transfer the data to an isolated background process that has access to protected storage.

The following article discussed the best practices of implementing background jobs using Microsoft Technologies.

https://azure.microsoft.com/en-us/documentation/articles/best-practices-background-jobs/

Dealing with Problems

Background jobs often require multiple steps to finish. Some of these steps may fail. The following design patterns are in place for dealing with failures.

  • Scheduler, Agent, Supervisor pattern. https://msdn.microsoft.com/library/dn589780.aspx. This pattern uses a scheduler to coordinate the tasks would require to complete a job. The decomposition of the job into inter-dependent tasks is typically done by a work-flow engine. The scheduler invokes agents to perform each task. An agent will deal with some of the failed scenarios for the task. Based on the agent’s response, the scheduler will update the task status. A supervisor will monitor the status of the tasks, and will invoke recovery agent to deal with the failure.

Some Example Usages

One example of the use of background jobs is in an invoice processing automation system. In this system, the following functionalities are being implemented using background jobs:

  • The data integration (data import and export)
  • The pricing of invoices
  • The settlement of invoices
  • Batch actions from UI
  • Processing bundled invoices

The system follows the scheduler/agent/supervisor pattern to implement a  job processing systems.

Another example of background jobs is in the Capital Management System. The following functionalities are being implemented using background jobs:

  • Data importing.
  • Date-end processing.
  • Batch transaction importing from UI.

 

Strategies for Mapping Inheritance Structures into Relational Database Tables

In designing a complex system, we would usually perform an business entity analysis to identify all the objects the system will manipulate to provide the functionalities. These objects would often need to be stored into relational database tables. This article is an extract on different strategies on performing such a task.

Relational databases do not natively support inheritance, forcing you to map the inheritance structures within your object schema to your data schema. Although there is somewhat of a backlash against inheritance within the object community, due in most part to the fragile base class problem, my experience is that this problem is mostly due to poor encapsulation practices among object developers than with the concept of inheritance. What I’m saying is that the fact you need to do a little bit of work to map an inheritance hierarchy into a relational database shouldn’t dissuade you from using inheritance where appropriate.The concept of inheritance throws in several interesting twists when saving objects into a relational DB.  How do you organize the inherited attributes within your data model? In this section you’ll see that there are three primary solutions for mapping inheritance into a relational database, and a fourth supplementary technique that goes beyond inheritance mapping. These techniques are:

To explore each technique I will discuss how to map the two versions of the class hierarchy presented in Figure 4.  The first version depicts three classes – Person, an abstact class, and two concrete classes, Employee and Customer.  You know that Person is abstract because its name is shown in italics. In older versions of the UML the constraint “{abstract}” would have been used instead.  The second version of the hierarchy adds a fourth concrete class to the hierarchy, Executive. The idea is that you have implemented the first class hierarchy and are now presented with a new requirement to support giving executives, but not non-executive employees, fixed annual bonuses. The Executive class was added to support this new functionality.For the sake of simplicity I have not modeled all of the attributes of the classes, nor have I modeled their full signatures, nor have I modeled any of the operations.  This diagram is just barely good enough for my purpose, in other words it is an agile model. Furthermore these hierarchies could be approved by applying the Party analysis pattern or the Business Entity analysis pattern. I haven’t done this because I need a simple example to explain mapping inheritance hierarchies, not to explain the effective application of analysis patterns – I always follow AM’s Model With A Purpose principleFigure 4.  Two versions of a simple class hierarchy.

Inheritance can also be a problem when it’s misapplied – for example, the hierarchy in Figure 4 could be better modeled via the Party (Hay 1996, Fowler 1997) or the Business Entity (Ambler 1997) patterns. For example, if someone can be both a customer and an employee you would have to objects in memory for them, which may be problematic for your application. I’ve chosen this example because I needed a simple, easy to understand class hierarchy to map.

2.1 Map Hierarchy To A Single Table

Following this strategy you store all the attributes of the classes in one table.  Figure 5 depicts the data model for the class hierarchies of Figure 4 when this approach is taken. The attributes of each the classes are stored in the table Person, a good table naming strategy is to use the name of the hierarchy’s root class, in a very straightforward manner.

Figure 5. Mapping to a single table.

Two columns have been added to the table – PersonPOID and PersonType. The first column is the primary key for the table, you know this because of the <<PK>> stereotype, and the second is a code indicating whether the person is a customer, an employee, or perhaps both. PersonPOID is a persistent object identifier (POID), often simply called an object identifier (OID), which is a surrogate key.  I could have used the optional stereotype of <<Surrogate>> to indicate this but chose not to as POID implies this, therefore indicating the stereotype would only serve to complicate the diagram (follow the AM practice Depict Models Simply).   Data Modeling 101 discusses surrogate keys in greater detail.The PersonType column is required to identify the type of object that can be instantiated from a given row.  For example the value of E would indicate the person is an employee, C would indicate customer, and B would indicate both. Although this approach is straightforward it tends to break down as the number of types and combinations begin to grow. For example, when you add the concept of executives you need to add a code value, perhaps X, to represent this. Now the value of B, representing both, is sort of goofy.  Furthermore you might have combinations involving executives now, for example it seems reasonable that someone can be both an executive and a customer so you’d need a code for this.  When you discover that combinations are possible you should consider applying the Replace Type Code With Booleans database refactoring, as you see in Figure 6.

For the sake of simplicity I did not include columns for concurrency control, such as the time stamp column included in the tables of Figure 2, nor did I include columns for data versioning.

Figure 6. A refactored approach.

2.2 Map Each Concrete Class To Its Own Table

With this approach a table is created for each concrete class, each table including both the attributes implemented by the class and its inherited attributes.  Figure 7 depicts the physical data model for the class hierarchy of Figure 4 when this approach is taken. There are tables corresponding to each of the Customer and Employee classes because they are concrete, objects are instantiated from them, but not Person because it is abstract. Each table was assigned its own primary key, customerPOID and employeePOID respectively. To support the addition of Executive all I needed to do was add a corresponding table with all of the attributes required by executive objects.

 

Figure 7. Mapping concrete classes to tables.

2.3 Map Each Class To Its Own Table

Following this strategy you create one table per class, with one column per business attributes and any necessary identification information (as well as other columns required for concurrency control and versioning).  Figure 8 depicts the physical data model for the class hierarchy of Figure 4 when each class is mapped to a single table.  The data for the Customer class is stored in two tables, Customer and Person, therefore to retrieve this data you would need to join the two tables (or do two separate reads, one to each table).The application of keys is interesting.  Notice how personPOID is used as the primary key for all of the tables. For the Customer, Employee, and Executive tables the personPOID is both a primary key and a foreign key.  In the case of Customer, personPOID is its primary key and a foreign key used to maintain the relationship to the Person table.  This is indicated by application of two stereotypes, <<PK>> and <<FK>>. In older versions of the UML it wasn’t permissible to assign several stereotypes to a single model element but this restriction was lifted in UML version 1.4.

Figure 8. Mapping each class to its own table.

A common modification that you may want to consider is the addition of a type column, or boolean columns as the case may be, in the Person table to indicate the applicable subtypes of the person.  Although this is additional overhead it makes some types of queries easier. The addition of views is also an option in many cases, an approach that I prefer over the addition of type or boolean columns because they are easier to maintain.

2.4 Map Classes To A Generic Table Structure

A fourth option for mapping inheritance structures into a relational database is to take a generic, sometimes called meta-data driven approach, to mapping your classes. This approach isn’t specific to inheritance structures, it supports all forms of mapping.  In Figure 9 you see a data schema for storing the value of attributes and for traversing inheritance structures. The schema isn’t complete, it could be extended to map associations for example, but it’s sufficient for our purposes. The value of a single attribute is stored in the Value table, therefore to store an object with ten business attributes there would be ten records, one for each attribute. The Value.ObjectPOID column stores the unique identifier for the specific object (this approach assumes a common key strategy across all objects, when this isn’t the case you’ll need to extend this table appropriately).  The AttributeType table contains rows for basic data types such as data, string, money, integer and so on.  This information is required to convert the value of the object attribute into the varchar stored in Value.Value.

Figure 9. A generic data schema for storing objects.

Let’s work through an example of mapping a single class to this schema. To store the OrderItem class in Figure 2 there would be three records in the Value table.  One to store the value for the number of items ordered, one to store the value of the OrderPOID that this order item is part of, and one to store the value of the ItemPOID that describes the order item.  You may decide to have a fourth row to store the value of the lastUpdated shadow attribute if you’re taking an optimistic locking approach to concurrency control. The Class table would include a row for the OrderItem class and the Attribute table would include one row for each attribute stored in the database (in this case either 3 or 4 rows). Now let’s map the inheritance structure between Person and Customer, shown in Figure 4, into this schema. The Inheritance table is the key to inheritance mapping. Each class would be represented by a row in the Class table.  There would also be a row in the Inheritance table, the value of Inheritance.SuperClassPOID would refer to the row in Class representing Person and Inheritance.SubClassPOID would refer to the row in Class representing Customer. To map the rest of the hierarchy you require one row in Inheritance for each inheritance relationship.

2.5 Mapping Multiple Inheritance

Until this point I have focused on mapping single inheritance hierarchies, single inheritance occurs when a subclass such as Customer inherits directly from a single parent class such as Person.  Multiple inheritance occurs when a subclass has two or more direct superclasses, such as Dragon directly inheriting from both Bird and Lizard in Figure 10.  Multiple inheritance is generally seen as a questionable feature of an object-oriented language, since 1990 I have only seen one domain problem where multiple inheritance made sense, and as a result most languages choose not to support it. However, languages such as C++ and Eiffel do support it so you may find yourself in a situation where you need to map a multiple inheritance hierarchy to a relational database.Figure 10 shows the three data schemas that would result from applying each of the three inheritance mapping strategies. As you can see mapping multiple inheritance is fairly straightforward, there aren’t any surprises in Figure 10.  The greatest challenge in my experience is to identify a reasonable table name when mapping the hierarchy into a single table, in this case Creature made the most sense.

Figure 10. Mapping multiple inheritance.

2.6 Comparing The Strategies

None of these mapping strategies are ideal for all situations, as you can see in Table 1.  My experience is that the easiest strategy to work with is to have one table per hierarchy at first, then if you need to refactor your schema according. Sometimes I’ll start by applying the one table per class strategy whenever my team is motivated to work with a “pure design approach”. I stay away from using one table per concrete class because it typically results in the need to copy data back and forth between tables, forcing me to refactor it reasonably early in the life of the project anyway. I rarely use the generic schema approach because it simply doesn’t scale very well.It is important to understand that you can combine the first three strategies – one table per hierarchy, one table per concrete class, and one table per class – in any given application.  You can even combine these strategies in a single, large hierarchy.

Table 1. Comparing the inheritance mapping strategies.

Strategy Advantages Disadvantages When to Use
One table per hierarchy Simple approach.Easy to add new classes, you just need to add new columns for the additional data.Supports polymorphism by simply changing the type of the row.Data access is fast because the data is in one table.Ad-hoc reporting is very easy because all of the data is found in one table. Coupling within the class hierarchy is increased because all classes are directly coupled to the same table.  A change in one class can affect the table which can then affect the other classes in the hierarchy.Space potentially wasted in the database.Indicating the type becomes complex when significant overlap between types exists.Table can grow quickly for large hierarchies. This is a good strategy for simple and/or shallow class hierarchies where there is little or no overlap between the types within the hierarchy.
One table per concrete class Easy to do ad-hoc reporting as all the data you need about a single class is stored in only one table. Good performance to access a single object’s data. When you modify a class you need to modify its table and the table of any of its subclasses.  For example if you were to add height and weight to the Person class you would need to add columns to the Customer, Employee, and Executive tables.Whenever an object changes its role, perhaps you hire one of your customers, you need to copy the data into the appropriate table and assign it a new POID value (or perhaps you could reuse the existing POID value). It is difficult to support multiple roles and still maintain data integrity. For example, where would you store the name of someone who is both a customer and an employee? When changing types and/or overlap between types is rare.
One table per class Easy to understand because of the one-to-one mapping. Supports polymorphism very well as you merely have records in the appropriate tables for each type. Very easy to modify superclasses and add new subclasses as you merely need to modify/add one table.Data size grows in direct proportion to growth in the number of objects. There are many tables in the database, one for every class (plus tables to maintain relationships). Potentially takes longer to read and write data using this technique because you need to access multiple tables.  This problem can be alleviated if you organize your database intelligently by putting each table within a class hierarchy on different physical disk-drive platters (this assumes that the disk-drive heads all operate independently). Ad-hoc reporting on your database is difficult, unless you add views to simulate the desired tables. When there is significant overlap between types or when changing types is common.
Generic schema Works very well when database access is encapsulated by a robust persistence framework.It can be extended to provide meta data to support a wide range of mappings, including relationship mappings.  In short, it is the start at a mapping meta data engine.It is incredibly flexible, enabling you to quickly change the way that you store objects because you merely need to update the meta data stored in the Class,Inheritance, Attribute, and AttributeType tables accordingly. Very advanced technique that can be difficult to implement at first.It only works for small amounts of data because you need to access many database rows to build a single object.You will likely want to build a small administration application to maintain the meta data. Reporting against this data can be very difficult due to the need to access several rows to obtain the data for a single object. For complex applications that work with small amounts of data, or for applications where you data access isn’t very common or you can pre-load data into caches.

– See more at: http://www.agiledata.org/essays/mappingObjects.html#sthash.plZN2eok.dpuf

Javascript MVVM/MVC Framework for Building Single Page App

single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. 

Modern browsers that can parse HTML5 allow developers to shift the UI and application logic from web servers to the client. Mature open-source libraries support building of SPA without digging too deep into JavaScript trenches and fighting with technology problems.

There are few distinct characteristics of the professional Single Page Application:

  • Chunking – the web page is constructed by loading chunks of HTML fragments and JSON data instead of receiving full HTML from a web server on every request. (Backbone.js, pjax, jQuery, Upshot.js)
  • Controllers – JavaScript code that handles complex DOM and data manipulations, application logic and AJAX calls is replaced by controllers that separate views and models using MVC or MVVM patterns. (Backbone.js, Knockout.jsJavascriptMVC)
  • Templating – coding of UI and DOM manipulations are replaced by declarative binding of data to HTML templates. (Knockout.js, Mustache, jQuery Templates,Underscore.js)
  • Routing – selection of views and navigation (without page reloads) that preserves page state, elements and data (History.js, Crossroads.js, Backbone.js, pjax,HTML5 History API)
  • Real-time communication – two-way communication of a client application and web server replaces one-way requests from a browser (HTML5 Web Sockets,Socket.ioSignalR)
  • Local storage – capabilities of storing data on a browser for performance and offline access replace cookies and intensive data loads from web server (HTML5 Local storage).

The following table presents a comparison of several important aspects for Seven popular JavaScript frameworks.

Views

URL routing

Data storage

AngularJS

Built-in DOM-based templates (mandatory)

Built-in (optional)

Built-in system (optional)

Backbone

Choose your own (most used handlebars.js, a string-based template library)

Built-in (optional)

Built-in (overridable)

Batman

Built-in DOM-based templates (mandatory)

Built-in (mandatory)

Built-in system (mandatory)

CanJS

Built-in string-based templates (mandatory)

Built in (optional)

Built in (optional)

Ember

Built-in string-based templates (mandatory)

Built-in (mandatory)

Built-in (overridable)

Knockout

Built-in DOM-based templates (optional, can do string-based too)

Choose your own (most use sammy.js or history.js)

Choose your own (e.g., knockout.mapping or just $.ajax)

Meteor

Built-in string-based templates (mandatory)

Built-in (mandatory?)

Built-in (Mongo, mandatory)

Spine

Choose your own string-based templates

Built-in (optional)

Built-in (optional?)

Backbone
  • Who: Jeremy Ashkenas and DocumentCloud
  • What:
    • Model-View in JavaScript, MIT licensed
    • Most minimal of all the libraries — only one file, 800 lines of code!
    • Extremely tightly-scoped functionality — just provides REST-persistable models with simple routing and callbacks so you know when to render views (you supply your own view-rendering mechanism).
    • The best-known of them all, with the most production deployments on big-name sites (perhaps easy to adopt because it’s so minimal)
  • Why:
    • It’s so small, you can read and understand all of the source before you use it.
    • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
  • WhereGitHub and own site
  • When: In production for nearly 2 years now
Meteor
  • Who: The Meteor development group, who just raised $11.2 Million so they can do this full-time
  • What:
    • Crazy amazing framework from the future, barely reminiscent of anything you’ve ever seen (except perhaps Derby)
    • Bridges a server-side runtime (on Node+Mongo) with a client-side one, so your code appears to run on both, including the database. WebSockets syncs between all client(s) and server.
    • Does “live deployments” every time you edit your code – client-side runtimes are updated on the fly without losing their state
    • Makes more sense if you watch the video
  • Why: You’ve had enough of conventional web development and now want to live on the bleeding edge.
  • WhereGitHub and own site
  • When: It’s still early days; I don’t know if there are any production Meteor sites yet except built by the core team. They’re totally serious about doing this, though.
Ember
  • Who: Yehuda Katz (formerly of jQuery and Rails), the Ember team, and Yehuda’s company Tilde
  • What:
    • Everything you need to build an “ambitious web application”, MIT license
    • Biggest framework of them all in both functionality and code size
    • Lots of thought has gone into how you can decompose your page into a hierarchy of controls, and how this ties in with a statemachine-powered hierarchical routing system
    • Very sophisticated data access library (Ember.Data) currently in development
    • Intended to control your whole page at runtime, so not suitable for use in small “islands of richness” on a wider page
    • Pretty heavily opinionated about files, URLs, etc., but everything is overridable if you know how
    • Design inspired by Rails and Cocoa
    • Tooling: They supply project templates for Rails (but you can use other server platforms if you write the code manually)
  • Why: Common problems should have common solutions — Ember makes all the common solutions so you only have to think about what’s unique to your own application
  • WhereGitHub and own site
  • When: Not yet at 1.0, but aiming for it soon. API will solidify then.
AngularJS
  • Who: Developed by Google; used internally by them and MIT licensed.
  • What:
    • Model-View-Whatever in JavaScript, MIT licensed
    • DOM-based templating with observability, declarative bindings, and an almost-MVVM code style (they say Model-View-Whatever)
    • Basic URL routing and data persistence built in
    • Tooling: they ship a Chrome debugger plugin that lets you explore your models while debugging, and a plugin for the Jasmine testing framework.
  • Why:
    • Conceptually, they say it’s a polyfill between what browsers can do today and what they will do natively in a few years (declarative binding and observability), so we should start coding this way right now
    • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
  • WhereGitHub and own site
  • When: In production now (has been at Google for a while)
Knockout
  • Who: The Knockout team and community (currently three on the core team, including me)
  • What:
    • Model-View-ViewModel (MVVM) in JavaScript, MIT licensed
    • Tightly focused on rich UIs: DOM-based templates with declarative bindings, and observable models with automatic dependency detection
    • Not opinionated about URL routing or data access — combines with arbitrary third-party libraries (e.g., Sammy.js for routing and plain ajax for storage)
    • Big focus on approachability, with extensive documentation and interactive examples
  • Why:
    • Does one thing well (UI), right back to IE 6
    • No impact on your server architecture or file layout. Can work in a small section of your page — doesn’t need to control whole page.
  • WhereGitHub and own site
  • When: In production for nearly 2 years now
Spine
  • Who: Alex MacCaw
  • What:
    • MVC in JavaScript, MIT license
    • Worked example originally written for an O’Reilly book grew into an actual OSS project
    • Is a kind of modified clone of Backbone (hence the name)
  • Why: You like Backbone, but want a few things to be different.
  • WhereGitHub and own site
  • When: It’s past v1.0.0 now
Batman
  • Who: the team at Shopify (an eCommerce platform company)
  • What:
    • MVC in JavaScript, almost exclusively for Rails+CoffeeScript developers, MIT licensed
    • Most opinionated of them all. You must follow their conventions (e.g., for file layout and URLs) or, as they say in their presentation,”go use another framework
    • Full-stack framework with pretty rich models, views, and controllers and routing. And observability mechanism of course.
    • DOM-based templating.
  • Why: If you use Rails and CoffeeScript, you’ll be right at home
  • WhereGitHub and own site
  • When: Currently at 0.9. Aiming for 1.0 in coming months.
CanJS
  • Who: the team at Bitovi (a JavaScript consulting/training company)
  • What:
    • MVC in JavaScript, MIT licensed
    • REST-persistable models, basic routing, string-based templating
    • Not widely known (I hadn’t heard of it before last week), though is actually a reboot of the olderJavaScriptMVC project
  • Why: Aims to be the best of all worlds by delivering features similar to the above libraries while also being small
  • Where: GitHub and own site
  • When: Past 1.0 already

 

41 Things You Need to Know about the Scaled Agile Framework® (SAFe)

Most of us working in agile software development are interacting with the same development team. Therefore, we are very intimate with the twists and turns of the flow within this team. However, when you look at it from the enterprise level, you would notice a lot of questions that may not have answers from the traditional agile teachings.

The Scaled Agile Framework®, or SAFe, provides a recipe for adopting Agile at enterprise scale. As Scrum is to the Agile team, SAFe is to the Agile enterprise. Therefore, it is important to know this framework if you want to make agile work within an enterprise.

1. SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale. It is field-tested and enterprise-friendly.
2. SAFe is the brainchild of Dean Leffingwell.

As Ken Schwaber and Jeff Sutherland are to Scrum,
Dean Leffingwell is to SAFe.

1. SAFe is based on Lean and Agile principles.
2. There are three levels in SAFe:
* Team
* Program
* Portfolio

At the Team Level:

1. Scrum with XP engineering practices are used.
2. Design/Build/Test (DBT) teams deliver working, fully tested software every two weeks. There are five to nine members of each team.
3. Rally’s weekly TeamStart webinar series covers the basic practices at the team level.

At the Program Level:

1. SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program.
2. The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization.
3. SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
4. Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries.
5. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI.
6. PSIs provide a steady cadence for the development cycle. They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
7. New program level roles are defined
* System Team
* Product Manager
* System Architect
* Release Train Engineer (RTE)
* UX and Shared Resources (e.g., security, DBA)
* Release Management Team
8. In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles. If they have deep domain expertise, they are likely to fill the Product Manager role. If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
9. SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations. Rally provides regular public and private Leading SAFe certification classes.
10. SAFe makes a distinction between content (what the system does) and design (how the system does it). There is separate “authority” for content and design.
11. The Product Manager (Program Manager) has content authority at the program level. She defines and prioritizes the program backlog.
12. SAFe defines an artifact hierarchy of Epics – Features – User Stories. The program backlog is a prioritized list of features. Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level. Features decompose to User Stories which flow to Team-level backlogs.
13. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.
14. The System Architect has design authority at the program level. He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met. He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.
15. The UX Designer(s) provides UI design, UX guidelines and design elements for the teams. In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.
16. The Release Train Engineer (RTE) is the Uber-ScrumMaster.
17. The Release Management Team is a cross-functional team – with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.
18. Rally’s monthly Program webinar series provides an overview of Scaling Agile Programs with SAFe.

At the Portfolio Level:

1. PPM has a central role in Strategy, Investment Funding, Program Management and Governance.
2. Investment Themes drive budget allocations.
3. Themes are done as part of the budgeting process with a lifespan of 6-12 months.
4. Portfolio philosophy is centralized strategy with local execution.
5. Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes.
6. There are business epics (customer-facing) and architectural epics (technology solutions).
7. Business and architectural epics are managed in parallel Kanban systems.
8. Objective metrics support IT governance and continuous improvement.
9. Enterprise architecture is a first class citizen. The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.
10. SAFe patterns provide a transformation roadmap.

Legacy ApproachLean-Agile Pattern
Centralized control
Decentralized decision-making
Project overload
Continuous value flow
Detailed project plans
Lightweight business cases
Centralized annual planning
Decentralized, rolling wave planning
Work breakdown structures
Agile estimating and planning
Project-based funding
Agile Release Trains
Projects and PMBOK
Self-managing teams and programs
Waterfall milestones
Objective, fact-based measures and milestones.
Table above reproduced with permission of Leffingwell LLC and Scaled Agile Inc

1. Rally’s monthly Portfolio webinar series provides guidance on Lean | Agile approaches to PPM.

Adoption

1. Adoption focuses on identifying a value stream. A value stream is a sequence of activities intended to produce a consistent set of deliverables of value to customers. Value streams are realized via an Agile Release Train (ART).
2. SAFe poses questions to help identify value streams (ARTs):
* What program might adopt the new process the fastest?
* Which executives are ready for a transition?
* What are the geographical locations and how are the team members distributed?
* What programs are the most challenged, or represent the biggest opportunities?
3. When you identify a value stream, you go “All In” and “All at Once” for that train.
4. Rally is an SAI Gold Partner. Rally’s cloud-based solutions for managing the Agile development lifecycle directly support SAFe. Read two independent analyst reports that show why “Rally Software continues its leadership in Agile/Lean.[1]”

[1] The Forrester Wave™: Application Life-Cycle Management, Q4 2012

Connection Pooling in Software Applications

Opening/Closing database connections is an expensive process and hence connection pools improve the performance of execution of commands on a database for which we maintain connection objects in the pool. It facilitates reuse of the same connection object to serve a number of client requests. Every time a client request is received, the pool is searched for an available connection object and it’s highly likely that it gets a free connection object. Otherwise, either the incoming requests are queued or a new connection object is created and added to the pool (depending upon how many connections are already there in the pool and how many the particular implementation and configuration can support). As soon as a request finishes using a connection object, the object is given back to the pool from where it’s assigned to one of the queued requests (based on what scheduling algorithm the particular connection pool implementation follows for serving queued requests). Since most of the requests are served using existing connection objects only so the connection pooling approach brings down the average time required for the users to wait for establishing the connection to the database.

Connection pooling is used in web-based and enterprise applications and is handled by the application server. Here is how connection pooling works in J2EE:

The following diagram shows how the connection pooling works:

Connection Pooling in ADO.Net

When the connection is closed or disposed in ADO.NET, it is returned to the connection pool and remains idle for until a request for a new connection comes in. If none comes in within this period, the connection to the backend is closed and the connection instance is removed from the Connection Pool. If all the connections are in the pool are busy then new connection waits in the queue for the existing connections to be released .We can set max connections, connection Pool size, Connection Time out etc settings in the web.config.

The following key value pairs explain the connection pooling settings.

  • Connection Lifetime – The time of Connection Creation will be compared to the current time. If this period exceeds the Connection Lifetime value that is set, then object pooler destroys the connection. The default value is 0; this will give the maximum timeout for connection.
  • Connection Reset – To reset the connection after it was take out from the Connection pool. The default value is true.
  • Max pool size – Maximum number of connections allowed within the Connection pool. The value is 100 by default.
  • Min pool size – Minimum number of connections allowed within the Connection pool. The value is 0 by default.
  • Pooling – To set the connection Pooling if it is true, the connection is drawn from the pool or created if no connection available from the pool. The value is true by default.
  • Connection Timeout – Maximum Time (in secs) to wait for a free connection from the pool. The value is 15 by default.
  • Incr Pool Size – Controls the number of connections which are established, when all the connections are used. The value is 5 by default
  • Decr Pool Size – Controls the number of connections which are closed when most of the established connections are unused. The value is 1 by default

 

Points to Ponder

  • Disabling the connection pooling, infers that the connection object that is created by the user will not be re-used to any other user.
  • A Connection pool will be created when Open() method of connection object is called. If the same application is using multiple Connection Strings (say more than one) then multiple connection pools will be created corresponding to each connection string.
  • Connection Pooling is applied in ADO.Net by default.
  • Connections that are not explicitly closed are not added or returned to the pool. Hence The Close() or Dispose() method of Connection need to be called to close the connection.
  • A Connection Pool is freed from the memory when the last connection to the database is closed.
  • Connection Pool’s life time is ended as soon as the application domain is unloaded. For example at any time when IISRESET runs the Connection Pool gets destroyed
  • Connection Pools cannot be shared across application domains.

 

 

Cloud, Virtualization, Devops, and “Infrastructure as Code”

In a traditional IT shop, OPs are responsible of setting up network and servers, installing and patching operating systems, and deploying software into the servers. By its nature, many of these steps are manual with the support of ad hoc automation scripts. As the number of servers growing rapidly in many organization, this operational approach has become increasingly inadequate. Manual steps and ad hoc automation scripts are labor-intensive and error-prone. They create many inconsistencies among servers that were supposed to have the same code.   It thus creates many mysterious phenomena in PROD environment that would take a lot of time and luck to figure out. Not surprisingly,  in such an environment, every PROD migration could be a disaster. A lot of fire-fighting followed after the major releases.

Devops is a movement to address the root cause of such a problem. This movement best enabled by the leverage of virtualization in modern data center and the utilization of “platform as a service” data center management strategy.

In his blog article, http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html, Adrian Cockcroft discussed how the OPs evolved from a traditional Ops, to DevOps, and to NoOps inside Netflix.

Here is his summary:

“In summary, Netflix still does Ops to run its datacenter DVD business. we have a small number of DevOps engineers embedded in the development organization who are building and extending automation for our PaaS, and we have hundreds of developers using NoOps to get their code and datastores deployed in our PaaS and to get notified directly when something goes wrong. We have built tooling that removes many of the operations tasks completely from the developer, and which makes the remaining tasks quick and self service. There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done, and less time spent actually doing ops tasks than developers would spend explaining what needed to be done to someone else. I think that’s different to the way most DevOps places run, but its similar to other PaaS enviroments, so it needs it’s own name, NoOps.”

As architects, why should we care about such a movement? That is because we are the ones who are responsible for producing a sound solution to the business problems. Inadequate OPs processes can produce a lot of pains and stresses on development teams.

What do you think of your operation processes?

 

Seven Commonly Used SOA Infrastructure

Service-oriented architecture is a way of thinking when building a large software system. In such an architecture style, functionalities are captured as services that can be developed, tested, deployed, and maintained separately from the rest of the system. A client of a service can discover and invoke operations on the service dynamically at runtime. The dynamic nature of service integration is often called service orchestration.

Apparently, business functionalities and their integration captured by the services and service orchestration vary from systems to systems. However, there are common non-functional concerns: security, logging, service discovery, messaging, etc. These concerns are implemented as SOA infrastructure. In other words, SOA infrastructure consists of system components/services that form a runtime environment where services and their orchestrations can be easily deployed.

The following diagram illustrates the result of a 2011 SearchSOA.com reader survey on the SOA infrastructure used by many SOA implementation.

 

XML appliances (from Wikipedia)

An XML appliance is a special purpose network device used to secure, manage and mediate XML traffic. They are most popularly implemented in Service Oriented Architectures to control XML based Web Services traffic, and increasingly in cloud oriented computing to help enterprises integrate on premise applications with off premise cloud hosted applications. XML Appliances are also commonly referred to as SOA Appliances, SOA Gateways, XML Gateways, Cloud Brokers. Some have also been deployed for more specific applications like Message-oriented middleware. While the originators of the product category deployed exclusively as hardware, today most XML Appliances are also available as software gateways and virtual appliances for environments like VMWare. XML appliances became a popular way of controlling or governing SOA because addressed message security, availability and translation of data so that an application can call another application irrespective of the data format and security policies.

 

Virtualizing Testing Environment

Here are other articles on this subject.

As an architect, why should you care about testing? For the following reasons:

  1. Software quality can only be built in. As the technical leader for a development organization, an architect must take the responsibility of building high quality software.
  2. As mentioned in many blog articles, testability of a software system highly depends on the architecture design.
  3. Having a broad knowledge on the best tools and technologies, architects can help the team to leverage such tools and technologies to improve the efficiency of testing.

Virtualizing and automating testing environments make it a lot easier to manage testing environment. For example:

  • You can easily clone a particular testing environment so that you can start deploying new code without affecting the testing of the existing code.
  • You can take a snap-shot of the environment in order to roll back the new deployment/states.

With modern virtual machine managing capabilities, it is quite easy to build such capabilities.

The first thing is to identify hardware you would need to support the DEV labs. Once that is done,  you’re ready to build your laboratory environment.

Follow these steps to set up your new virtual laboratory.

  1. Start with the base server configuration for the host servers.This means installing additionalRAM, network adapters and disks as required.
  2. Begin the base server installation for the host servers.This means installing the hypervisor on bare-metal machines.
  3. Plan adequate storage space, an average of 500GB or more, for the following:
    •  Storing all laboratory data
    •  ISO or DVD files for all required operating systems and software
    • VM images that will be created during all testing
    • Backup data of virtual hard disks
  4. Download and prepare the VM for evaluation tools.
  5. Create new VMs or transform existing physical machines intoVMs.
  6. Build multiple environments to support testing graduations.
  7. Prepare a self-service portal for end users to manage their ownVMs.

 

A Summary of Common Architecture Styles

The following table lists the common architectural styles.

Architecture style Description
Client/Server Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures.
Component-Based Architecture Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.
Domain Driven Design An object-oriented architectural style focused on modeling a business domain and defining business objects based on entities within the business domain.
Layered Architecture Partitions the concerns of the application into stacked groups (layers).
Message Bus An architecture style that prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.
N-Tier / 3-Tier Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
Object-Oriented A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.
Service-Oriented Architecture (SOA) Refers to applications that expose and consume functionality as a service using contracts and messages.

This table is extracted from (http://msdn.microsoft.com/en-us/library/ee658117.aspx). The article also gives a big more details on each of these architecture styles.