Software Engineering, Project Management, and Effectiveness
“People only see what they are prepared to see.” - Ralph Waldo Emerson
At the beginning of the year, I like to take a quick survey of the Microsoft application platform. It helps me figure out where to put my bets and where to explore. It’s a “see the forest, from the trees” exercise.
And oh, what a forest it is. The beauty is it covers a wide spectrum and supports so many scenarios. The challenge is finding your way around. To find my way around, I map out the platform and I think in terms of application types:
By thinking about deployment targets such as cloud or desktop or browser or phone, etc. it makes it very easy to get in the ballpark in terms of context and technologies very quickly. From there, I can worry about things like presentation or data access stacks or language platforms (native, .NET, or scripting.) It’s also a quick way to explore relevant quality attributes (security, performance, reliability) or evaluate architectural styles. In other words, it’s a way to hack through information overload and cut to the chase.
Microsoft Application Platform at a Glance This is my draft map of the platform. It’s a strawman that I use to walk the platform, find clusters of technologies, figure out what’s changed, and evaluate the latest story. It’s easier for me to have conversations about the platform with customers or product teams when I start with a shared frame. The hard part is putting the initial map together. The easy part is improving it through feedback. If something is missing, it’s easy to add. If something is wrong, it’s easy to fix.
As simple as the map looks, it compacts a lot of information. I stuck the code names in where I could find them. Enjoy …
Where To Find Out More I’m a fan of teaching people to fish, as well as giving some starter fish. Aside from people, events, and social media, the three best ways I know to figure out what’s happening on the platform are Wikipedia, Channel9, and the MSDN Dev Centers. I started you out with some pages below …
Channel9 Training Centers
MSDN Dev Centers
This is my current mental model for Virtual Machines (VMs) for Web and Worker Roles in Windows Azure:
On Windows Azure, you run your application in Web and Worker Roles. Each instance of a Web or Worker Role runs in a VM. You define how many instances of each Web or Worker role you want to run. Windows Azure then spins up a VM for each instance. You can choose from 4 flavors of VMs: one core, two core, four core, and eight core.
Here is a summary of the key components:
The load balancer spreads the incoming HTTP or HTTPS requests across your Web Role instances.
For a higher-level view, see my related post, Windows Azure Platform at a Glance.
This is my first attempt at parsing and summarizing the Windows Azure Platform, so I expect it to evolve as I iterate on it.
The Windows Azure platform is a set of cloud computing services for creating and consuming cloud applications and services. The key components of the Windows Azure Platform are:
You can use the Windows Azure Platform from your applications running in the cloud and from on-premises applications. For example, you might access data in the cloud from an on-premises app, or you might access local user accounts from an app in the cloud.
Windows Azure Windows Azure provides compute, storage, and management through Microsoft data centers. The key components are:
For more on Windows Azure, see Windows Azure SDK (MSDN.)
SQL Azure SQL Azure provides cloud-based services for relational databases, reporting and analytics, and data synchronization. The main component is a SQL Azure Database:
For more information on SQL Azure, see SQL Azure (MSDN.)
App Fabric Windows Azure platform AppFabric (formerly called “.NET Services”) provides common application infrastructure services for distributed applications. The key components are:
For more on App Fabric, see App Fabric Service Bus (MSDN) and App Fabric Access Control (MSDN.)
For more information on the Windows Azure Platform, here are some of the main Azure starting points:
In cloud computing, you might hear the terms SaaS, PaaS and IaaS. These are simply different logical layers in the stack. You can visualize it like this:
As you move up the stack, you increase abstraction. As you move down the stack, you increase control. Here is a brief summary of each term:
For my related posts on cloud, see:
“Nature is a mutable cloud which is always and never the same.” – Ralph Waldo Emerson
It’s tough to talk about clouds until we have a simple, working definition. While ramping for Azure Security guidance, we defined the cloud as follows:
A cloud is a managed infrastructure providing network, compute, and storage capabilities. It has the following 3 key characteristics:
This simple frame helps us identify what is cloud, and what is not.
That’s not the only definition in town though. Here are a few others that I found useful ...
Berkeley Cloud Definition In Above the Clouds: A Berkeley View of Cloud Computing, U.C. Berkeley Reliable Adaptive Distributed Systems Laboratory define the cloud as follows:
“Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the datacenters that provide those services. ... From a hardware point of view, three aspects are new in Cloud Computing.
In A Break in the Clouds: Towards a Cloud Definition In A Break in the Clouds: Towards a Cloud Definition, Vaquero et al define cloud as follows:
“Clouds are a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically re-configured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay- per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs.”
What’s your working definition of “cloud” that you’ve found helpful?
“It is not necessary to change. Survival is not mandatory.”—Edwards Deming
I gave a talk for the developer security MVPs at the Microsoft 2010 MVP Summit last week. While I focused primarily on Azure Security, I did briefly cover Agile Security Engineering. Here is the figure I used to help show how we do Agile Security Engineering in patterns & practices:
What’s important about the figure is that it shows an example of how you can overlay security-specific techniques on an existing life cycle. In this case, we simply overlay some security activities on top of an Agile software cycle.
Rather than make security a big up front design or doing it all at the end or other security approaches that don’t work, we’re baking security into the life cycle. The key here is integrating security into your iterations.
Here is a summary of the key security activities and how they play in an agile development cycle:
The sum of these activities is more than the parts and using a collection of proven, light-weight activities that you can weave into your life cycle helps you stack the deck in your favor. This is in direct contrast to relying on one big silver bullet.
Note that we originally used “reviews” which are more exploratory, but we later optimized around “inspections.” The distinction is that inspections use criteria (e.g. a 12 point inspection.) We share the criteria using security checklists for design, coding, and deployment inspections.
There are two keys to chunking up security so that you can effectively focus on it during iterations:
Stories are a great way of chunking up value. Each story represents a user performing a useful goal. As such, you can also chunk up your security work, by focusing on the security concerns of a story.
A security frame is a lens for security. It’s simply a set of categories or “hot spots” (e.g. auditing and logging, authentication, authorization, configuration management, cryptography, exception management, sensitive data, session management.) Each category is a container for principles, patterns, and anti-patterns. By grouping your security practices into these buckets, you can more effectively consolidate and leverage your security know-how during each iteration. For example, one iteration might have stories that involve authentication and authorization, while another iteration might have stories that involve input and data validation.
Together, stories and security frames help you chunk up security and bake it into the life cycle, while learning and responding along the way.
For more information on security engineering, see patterns & practices Security Engineering Explained.
“All models are wrong, some are useful.” – George Box
This is a simple visual model we’re using on our patterns & practices Azure Security guidance team to dialogue around cloud computing concepts.
Here are the key things to know:
Aside from providing a simple lens for looking at cloud computing, this model also helps us find important or interesting intersections across various cloud efforts in the industry. For example, this can help us connect the dots to NIST’s cloud computing work. We can find useful intersections at a model level, without getting lost in the weeds.