Is Azure Adoption “Too Easy”?

image

Those of you who know me know that I have been focusing on the adoption of Microsoft Azure since before it was actually called Azure (Circa 2008) when I originally stumbled upon it while working as an Architect for Microsoft. Since I had previously worked as a consultant to Bell Labs on the ill-fated AT&T NET1000 Cloud project as documented in The Slingshot Syndrome: Why America’s Leading Technology Firms Fail at Innovation) I immediately recognized its potential.

Since then we have seen a lot of companies adopt Azure and have helped many of them make the jump. Recently our focus has also skewed towards helping companies that may have jumped into Azure without adequate planning to remediate their architecture and their implementation.

Our experience is that it is very easy (perhaps too easy) to get into Azure without a well-thought-out architecture and a good plan. We cannot fault Microsoft for making it as simple as possible, however it is very easy to do it without adequate planning. In our InfoQ article The SaaS Development Lifecycle we outlined how a company should approach their first Azure project. Although published in 2011 IMHO it is still valid today.

At some point you will realize that you may have created what Grady Booch has called an “Accidental Architecture” or what Eric Evans and Brian Foote have called “A Big Ball of Mud”.  Smile

Azure Accounts

Note that there are typically two ways to experiment with Azure. Recently Azure introduced a simplified Free Trial model that give you access to a limited number of Azure resources over a 12 month period, some free resources indefinitely and a limited amount of Azure resources that burn-down against a 30 day allocation of metered usage.

The other way is to have an MSDN subscription which includes a monthly amount of free Azure resources as part of that subscription.  Since the Free Trial only presents a very limited set of options compared to an MSDN subscription, and since we want to discuss not only experimentation but real infrastructure and applications in Azure, we will use an MSDN subscription in this post.

You should also note that there are other non-Trial and non-Free pricing plans such as Pay-As-You-Go and Enterprise Agreements that are more relevant to production architectures.

The “Easy” path

As an example, let’s take the easy-path scenario.

You sign up for a free trial using your personal credit card and telephone number. (Just needed for identity verification, of course.)

Next you create a VM in Azure taking most of the default values presented during the creation process. You are amazed at how easy this is to do. Smile

image

Naming conventions are important.

You would never think of creating a physical or virtual machine on-premises without paying some consideration to a sensible naming convention. Take the same care here. The naming convention should take into consideration the type of resource (VM) as well as additional characters that serve to define the purpose and (perhaps) location of the VM. (The challenge here is to do this within the VM resource naming limitation of 15 characters.)

By the way, note that the VM here defaults to SSD (Solid State disk!). If you are just experimenting you should quickly change that to HDD to save money (or reduce free trial resource consumption).

Resource Groups are important.

Next you will be asked to specify the name of an existing or new resource group. Here a naming convention is also important and you should lay out your resource groups based on a naming convention that takes into consideration the purposes of resource groups. 

Over time there have been three purposes for Azure resource groups identified:

  1. As a LifeCycle container for resources that have the same life-cycle; which means that they contain resources that are normally created and/or destroyed together.
  2. For Role Based Access Control in the case where different departments in a company need to exercise control over a subset of all resources. An example might be a Network Management group that needs to “own” all network related resources in Azure.
  3. For Billing and Charge-back purposes; although the need for this has been largely supplanted due to the use of Resource Tagging as a Billing and Charge-back mechanism.

Save money with Hybrid Use Benefits

If you have on-premises licenses for Windows Server you may be able to take advantage of a substantial discount (up to 40%) by applying your Hybrid Use Benefits (HUB). See the “Save Money” section above.

Choose a VM size

Next you get to choose the VM specs that you want to allocate. If you neglected to change SSD to HDD you can do it  here.

Although Azure only presents you with a few choices here you can see them all by clicking on the “View all” link. There are a lot! Pick one.

image

The next page is very important.

image

Availability Sets

Creating an Availability Set in Azure in order to maximize your service level and avoid downtime is a great feature of Azure. If you are just experimenting it is OK to leave High Availability set to None. In a production environment you will want at least two VMs in an Availability Set to maximize availability.

Managed Disks

Managed Disks great option. In most cases you should let Azure manage the storage for the VHDS that back the VMs that you create.

Network Considerations

Network Considerations are extremely important. In a production architecture you need to be explicit about your subscription (or subscriptions) as well as the environments that you want to support. Over time we have come to adopt a model that has a single subscription with VNets defined by environment (Dev, QA, Prod, DR, etc.).  Then each VNet is broken down, in turn, into SubNets for architectural tiers and specific purposes such as network gateways. You should give some detailed thought to this design.

All other items on this page should be given specific names rather than taking the defaults.

Before moving on pay particular attention to the Auto-shutdown feature. As you can see in the example the VM will be automatically shut down by Azure at 7PM. This is great feature to prevent burning through resources that you forgot you allocated. Turn it off if you don’t want that to happen. (It will not be restarted automatically the next day.)

At the end you will see an excellent summary of what you are about to create. Until you click on Create you haven’t created the VM.

image

What’s next?

Based on the above experience you start migrating servers and applications to Azure. You don’t spend much time thinking about things like naming conventions or other architectural considerations such as organizing resources into well managed resource groups.

At some point you will run out of your free resources  and change it to either a pay-as-you-go subscription or one of the other subscription types such as an Enterprise Agreement.

At this point you may not even be worrying about cost. That is until you get hit with the first bill from Microsoft that demonstrates the penalty for sloppy planning and careless resource utilization. Sad smile  (BTW: In Azure, unlike on-premises, you can  save money by shutting down VMs when they are not needed.  In one case we were able to save a company 40% of their Azure spend by identifying resources that could be shut down when not in use and automating that shutdown.)

Conclusion

As a consultant I can’t complain too much about this state of affairs, since we are often asked to come in, assess a client’s Azure architecture and make recommendations on how to remediate it. Sometimes the restructuring can be minor. In other cases, major surgery is required.

In subsequent blog posts we will discuss the better way to Adopt Azure or to remediate what you already have in Azure.  We will discuss how to perform a Current-state Assessment of your infrastructure and applications, develop a Migration/Remediation plan, as well as how to assess whether to retire, replace, migrate or reconfigure your current infrastructure and application resources.

Until then.

Bill Zack

Posted in Uncategorized | Leave a comment

Azure 2018 Global Bootcamp Event in Nashville

>>>> EVENT UPDATE  <<<<

We are looking forward to a great Bootcamp event this Saturday.

There have been some recent Agenda changes. (See below.)

Please arrive on time as Microsoft has informed us that the elevator will be locked on Saturday and we will have to send someone down to get you into the building from the parking garage. In an emergency you can contact my cell phone: 203 545-2339.

And please park on Level 2 of the parking garage (P2).

See you soon

image

As many of you know my “night job” Open-mouthed smile is to run the Nashville Microsoft Azure Users Group, a group that I founded with three other Azure enthusiasts five years ago. The group has now grown to over 760 members here in Nashville.

This year we will be hosting the Nashville edition of the 2018 Global Azure Bootcamp. It will be held on Saturday, April 21st, 2018 for an entire day, with food, raffle items, and more. Lots of fun, lots of learning.

For those unfamiliar, this is a global event with simultaneous local activities happening around the world. This will be our third year hosting the event in Nashville.

We have a full lineup of speakers that will be presenting in two parallel tracks over a full day.

In addition, the Microsoft Store will be setting up a Device Bar at the event to demonstrate an assortment of hardware devices.

We have the following local sponsors for the event:

  • Microsoft
  • Stratum Technology
  • Vaco
  • Provisions Group
  • Cardinal Solutions

Cardinal Solutions will be raffling off a Drone at the event.

Microsoft will be providing a free three-month Azure Pass Subscription for every Attendee.

We are also working on lining up additional sponsors for the event and the end-of-day raffle. Stay tuned for more details.

There will also be SWAG and raffle prizes donated by global partners arranged for by the Global Bootcamp committee. More details will follow soon.

If you have not registered yet unfortunately registration is now closed.

Bill Zack

Posted in Event, Microsoft Azure, User Groups | Leave a comment

Azure: What to use When?

image

On August 17, 2017 I presented on the topic of Azure: What to use When? To the Nashville Microsoft Azure Users Group. For those of you who know me you know that I founded this group four years ago with four members and, as of today, we are at 621.  You also may know that I  have been working with Azure since before it was called Azure. Although I would like to claim all of the credit for this recent growth I do have to credit the tremendous success of Azure over that time. Smile

In any case, this is a blog post about that presentation.

In IT things are clearly moving from a CapEx to an OpEx model where the focus is shifting from internal data center and hosted applications into the Cloud with its consumption based pricing model. The lure of pay-as-you go pricing is attractive; but it does carry with it some risk. If you choose the wrong applications to move into the cloud it could wind up costing you more than running them locally or at a hosting provider. It also requires increased discipline related to allocation and deallocation of Cloud resources.

In the presentation, we started off with a discussion of these considerations, and then explored the features supported by Microsoft Azure.

The presentation included an architectural overview of the Azure platform, its features and services. Since Azure is a very broad offering, we focused on the question of what the Azure Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) features are, and when they should be used to solve specific business and technical problems.

This presentation was targeted at new Azure user as well as existing users that might not be conversant with all of its recent enhancements. We covered the entire platform with a comprehensive overview, not too deep but deep enough, to understand what to use when.

Agenda
• What is Azure?
• Why adopt it?
• Azure Resource Management
• Compute Options
• Azure Storage
• Databases
• Business Continuity (Backup and Disaster Recovery)
• Networking
• Security
• Virtual Desktop
• IoT & Analytics
• The Future of Azure

Bill Zack August 22nd, 2017

Posted in Architecture, Cloud, Cloud Computing, Governance, IaaS, Linux, Microsoft Azure, Microsoft Azure WebApps, Microsoft Azure WebJobs, PaaS, SaaS, Security, SQL Azure, User Groups, Windows Azure, Windows Azure Web Sites | Tagged | Leave a comment

What is your Azure Maturity Level?

image

Figure 1 – The Azure Maturity Model

The Azure Maturity Model is based on the Cloud Maturity Model developed by the Open Data Center Alliance. Its purpose is to help you determine where you stand in your ability to adopt the cloud successfully.

We have adopted it and adapted it to be an Azure Maturity Model for guiding companies that are at various stages in their adoption of Azure. We have also used it to structure our Azure service offerings to match what is needed by companies at various levels of maturity.

The Azure Maturity Model

The Azure Maturity Model levels are shown in Figure 1.

Azure Watchers are organizations that are developing cloud strategies and plans but have not yet deployed applications or workloads into Azure. Azure Watchers want to evaluate available cloud options and determine which applications or workloads to implement in the cloud.

Azure Starters are new to cloud computing and are working on proof-of-concepts or initial Azure cloud projects. Azure Starters want to gain experience with cloud in order to determine future projects.

Azure Explorers have multiple applications or workloads already deployed in Azure. Azure Explorers are focused on improving and expanding their use of cloud resources.

Azure Focused companies are already heavily using Azure and are looking to optimize their Azure cloud operations and costs.

How to tell where you are.

To determine your maturity level, you must be honest with yourself and do a self-evaluation based on the above criteria. Or you could hire an experienced consultant to come in and help you do it . Smile

How to get to the next level (and why you want to)

Regardless of the level of Azure maturity that you are at you will need to look at your existing applications and workloads in terms of factors such as

  • Competitive pressures forcing you to the cloud
  • The shift from Capex to OpEx and Cost Control
  • Your desire for agility in capacity
  • The need for a hybrid architecture leveraging the cloud and on-premises resources with each other.

Workloads that cry out to be moved to the cloud

One of the primary reasons for moving to Azure has to do with Capacity Planning and Scalability. Capacity Planning in the data center is often a linear process. An IT director must make an estimate of the company’s capacity requirements over time, in most cases on a yearly basis. Then it is their job to make sure that those requirements are met. Ideally there should be no time during which capacity is wasted and no time during which the capability needed by the business is not available.

Unfortunately, reality is messy, and the capacity needs of the business are never represented by a straight line. (See the curved line in Figure 2 for a typical example.)

Adding to the difficulty of matching capacity to requirements is the server quantum effect. You cannot normally buy and bring in servers of the exact size and timing to match the real demand curve. So, you have to buy servers in relatively large chunks as shown in the step-function in Figure 2

image

 

 

Figure 2 – Data Center Capacity

Contrast that with Figure 3 which shows that in Azure it is possible to match capacity requirements to available capacity because of the ability to scale up and scale down as needed to match demand.

image

 

Figure 3 – The Azure View

Applications and Workloads fit for Azure

Of course, Scalability is important, but it is not the whole story. You also have to look carefully at the applications and workloads that you have in your data center that you may want to move to Azure. You need to consider their “fitness” for the cloud. Figure 4 (from the dawn of Azure) seeks to define the characteristics of application (and workload) types that are “Fit for the Cloud”.

image

Figure 4 – Workload Patterns

Predictable Bursting

This is the pattern that started the Cloud revolution. We do have to give Amazon credit for this. Having a lot of capacity during the Christmas season that remained idle most of the year they decided to sell that idle capacity.

Examples of Predictable Bursting are the Christmas Rush I retail (the Amazon pattern), Tax Season in CPA firms, etc.

On-Off

Given the ability to scale up and down in Azure a prime target are those applications and workloads that do not have to be always on. Examples might be processing that is only done at month-end, at end-of day or as otherwise required.

This is, by the way, a very significant pattern and one that can save a company a lot of money. One recent Migration Assessment that we performed for a client showed that they could save 35% of their entire compute costs by simply automating the shutdown and startup of Virtual Machines in Azure to match this pattern.

Growing Fast

I call this the “Grow-Fast” “Fail Fast” pattern. This is an application or workload that is new and may require a high level of resources. Or not. Only time will tell. No point in buying a lot of server capacity only to have it sit around idle if the expected demand does not materialize. An example might be a new web site that just might be the next Facebook. Or not.

Unpredictable Bursting

This one is a bit hard to distinguish form the predictable bursting case. This is the case where a lot of traffic hits your web site because Microsoft or Slashdot tells the world about it.  Initially there is heavy traffic to it, but it may not last. Again, no need to buy capacity that may not be needed in the long run.

Who is responsible for what in Azure?

There are multiple ways to move applications and workloads to Azure. They are: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). A third method Software as a Service (SaaS) is not actually a method supported by Azure as discussed below. These approaches differ primarily in who is responsible for the various levels of the hardware/software stack. The diagram below (also from the dawn of Azure) illustrates the typical on-premises hardware and software stack and contrasts it with your complete responsivity for everything in the data center to your more limited responsibilities in Azure.

image

Figure 5 – Cloud Services – Shared responsibility

Everything in black letters represents your responsibilities. The items in blue are handled by the cloud vendor, in our case by Microsoft Azure.

On-Premises

No issue here. You are responsible for everything. (Unless you contract out management of your infrastructure to a Managed Service provider that acts like you own IT staff).

IaaS

In IaaS, the vendor (Microsoft) is responsible for everything up to 1/2 of the OS layer. Why 1/2? Because, although Microsoft takes responsibility of most to the OS layer you are still responsible for performing maintenance such as patching the OS when fixes come out.

PaaS

PaaS was actually the first Azure service delivered back in 2010. IaaS was added after that to accommodate all the clients that wanted to get into the cloud quickly using a “Lift and Shift” approach to move applications and workloads to Azure. In PaaS, you have no responsibility for the non-application and data parts of the stack. You just bring your applicants and data to the stack and process it there. It should be mentioned that in many cases you can move applications to the cloud unmodified, however in some case they require modification (called “Modernization”) to make the transition successful and more cost effective.

SaaS

A discussion of SaaS is somewhat misplaced in a discussion of Azure, but it needs to be contrasted with IaaS and PaaS. In SaaS, the vendor has complete responsibility for the entire stack. You just use the service provided by the SaaS vendor. Of course, you do need to bring your data but the application processing is provided by them. Good examples of SaaS would be Microsoft’s Office 365 and (from the dawn of computing) ADP Payroll processing and QuickBooks. (Which are not often recognized as pioneers in the SaaS space, but they are.)

Conclusions

Making the decision to take a Lift and Shift approach with IaaS, to take a Modernization approach with PaaS or to take a provided service approach such as SaaS can be hard decision to make. When we help our clients make that decision through a process we call “Migration Assessment” we evaluate all the criteria above. Not to over-simplify but figure 6 illustrates the thought process of deciding between SaaS, PaaS and IaaS.

image

Figure 6 – When to Use What?

Clearly if you can find a SaaS solution that does the job for the right price adopt it.

If the application or workload is amenable to Modernization that might be the right choice. Effort expended in modifying it to run better in Azure might result in lower costs and fewer maintenance headaches.

If neither of those approaches are appropriate then you can always take the Lift and Shift approach provided by IaaS to get the application or workload into Azure quickly. Accountants think in terms of Return on Investment (ROI) and Total Cost of Operation (TCO). In a world where business needs change rapidly and it is difficult to predict the future Time to Value (TTV) can often be a more important determinant of what to move to the cloud first.

And yes, I know that we haven’t discussed the Hybrid approach (blending cloud and on-premises resources together) in this post. Microsoft is the number one cloud provider in the Hybrid space, but that will have to be saved for another post on another day. As Mark Twain once said, “Sorry for the length of this letter, I did not have time to make it shorter”  Smile

Brian Barnes

Bill Zack

August 2017

Posted in Cloud, Cloud Computing, Governance, Microsoft Azure, Windows Azure | Tagged , , , | 1 Comment

A Cloud is a Cloud is a Cloud?

It never fails to amaze me that it seems like every vendor in the industry, every hosting company and every virtualization or database vendor that puts something in one of the Public Clouds is quick to claim that “They have a Cloud”. A while back they even invented a term for that. The term is “CloudWashing” (i.e. naming everything that you have as “Cloud”)

Let’s apply some common sense. Back in 2011 the National Institute of Standards (NIST) produced a concise and clear definition of what it means for something to be a Cloud. You can read about it here. This is the standard against which all Cloud pretenders should be measured. In case you don’t have time to read it I will summarize.

The NIST model defines a Cloud as “Enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. (The underlining is mine)

It is composed of:

  • 5 Essential characteristics
  • 3 Service models
  • 4 Deployment models

The 5 essential characteristics are:

  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured service

The 3 Service Models are:

  • Software as a Service (SaaS)
  • Platform as a Service (PaaS)
  • Infrastructure as a Service (IaaS)

The 4 Deployment Models are:

  • Public Cloud
  • Private Cloud
  • • Community Cloud
  • • Hybrid Cloud

Let’s take the definitions apart a bit and see what makes them tick:

The 5 Essential Characteristics

On-demand self-service: Being able to self-provision and de-provision resources as needed, without vendor involvement.

Broad network access: Resources available over a network accessed through standard protocols from all kinds of devices. For Public Clouds, these resources are typically available all over the world with data centers that accommodate all country’s need for data sovereignty and locality.

Resource pooling: Lots of resources that can be allocated from a large pool. Often the user does not know, or have to know, their exact location. Although, in the case of Public Clouds like Microsoft Azure, locality is often under the user’s control. In many cases the pool of resources appears to be nearly infinite.

Rapid elasticity: The ability to scale up and down as needed at any time, in some cases automatically, based on policies set by the user.

Measured service: Providing the ability to track costs and allocate them.  Public Cloud resources are often  funded using an Operating Expenditure (OpEx) rather than the Capital Expenditure (CapEx) accounting model used where hardware purchases are involved.

The 3 Service Models

In the case of Public Clouds these service models are defined by who supports various levels in the technology stack; the customer or the cloud vendor.

This Microsoft Azure diagram has been in existence, in one form or another, at least since the 1970s:

clip_image002[4]

It illustrates who is responsible for what part of each service type the Vendor (in blue) and the customer (in black).

Software as a Service (SaaS) asks the customer to take no responsibility for the underlying hardware and software stack. In fact, the customers only responsibility is to use the service and pay for it.

Platform as a Service (PaaS) lets the vendor manage the lower layers of the technology stack, while the customer is responsible for the Application and Data layers.

Infrastructure as a Service (IaaS) corresponds most closely to what the customer must manages  in a typical data center and what the vendor is responsible for. With IaaS, the vendor takes care of everything from part of the operating system layer to the bottom of the stack. Notice that in Azure the operating system layer is partly the vendor’s responsibility, and partly the customer’s. The customer is still responsible for applying operating system patches, for instance. (This may differ slightly for other Public clouds.)

I often include a slide in my Cloud presentations that addresses the question of what to use when. In my mind the decision tree is fairly obvious:

  • It’s SaaS until it isn’t
    • Then It’s PaaS until it isn’t
      • Then It’s IaaS
  • Or Hybrid with any of the above

If you can find a SaaS service that meets your objectives, use it. Let the vendor have all the stack support headaches. If you can’t, then consider using PaaS by either buying a 3rd party application or building your own.

Finally, if none of these approaches work, you can always take advantage of IaaS since that most closely matches what you have in your own data center. Even there, however, the vendor will take care of a great deal of the plumbing. (As an aside IaaS is often the approach of choice for taking a “lift and shift” approach to migrating what you already have running in your data center up into the cloud.)

And yes, I know we haven’t discussed Hybrid yet, but patience, we will get there.

The 4 Deployment Models

A Public Cloud is a pool of computing resources offered by a vendor, typically, on a “pay as you go” basis. It supports Self-Provisioning by its customers as discussed above. It also often has a massive global presence and appears to have near-infinite capacity. In general, it is available to anyone.

Gartner defines a large number of Leadership Quadrants, but the ones that are most relevant to our discussion are the ones for Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). The Gartner Leadership Quadrant for IaaS includes just Amazon and Microsoft. The one for PaaS just includes Microsoft Azure and Salesforce. There are other lesser Public Cloud vendors including Google, IBM and Rackspace.

One other point: Unless a company can spend the many billions of dollars necessary to create a global datacenter presence it is hard for them to be considered a Public Cloud leader.

A Private cloud on the other hand is normally local to a single company. It is normally located on their own premises. If a customer creates a data center, or a complex of data centers, that conforms to the NIST definitions discussed herein then it can rightly be called a “Private Cloud”. Be cautious here, however. Remember the term “CloudWashing” as defined above. Just because a customer has a large number of computers in a data center does not make that a Private Cloud no matter how vehemently they insist on calling it one.

Although there is no requirement for the architecture of Public and Private Clouds to be the same most companies agree that compatibility between them would be helpful to support CloudBursting. That is, the ability to move applications and data freely between the data center and the Public Cloud. (See the discussion on Hybrid Cloud below.)

A Community Cloud is a variation of a Public Cloud that restricts its clientele to a specific community of users. For instance, there are Community Clouds for Government and Education as well as for other communities. Each of these may have different levels of security and compliance requirements or other unique characteristics. The NIST document does state that it may be operated for the community by one of the companies in it, however, it is typically operated by a Public Cloud vendor using a walled-off subset of it resources.

A Hybrid Cloud is typically formed by the integration of two or more Public and/or Private Clouds. In the typical case a company utilizes both a Public Cloud and resources in their own data center structured as a private cloud with strong networking integration between them.

A high degree of standardization between them is desirable in order to make it possible to distribute resources across them or to load balance or cloudburst resources between them. This is often done for security and compliance reasons where a company feels that some data and/or processing must remain behind their own firewall, while other data and/or processing can take advantage of a Public Cloud.

In the case of Microsoft technology there is one example where compatibility will be extremely high and advantageous. I expect the Private Cloud space to be dominated, at least in data centers utilizing Microsoft technology, by the new Azure Stack appliance coming out this summer from 5 initial vendors. Make no mistake about it. Azure Stack is Azure running in your own data center. In effect Azure stack is pretty much like Just another Azure Region  (JAAR?) to the Public Azure Cloud. Having that high degree of compatibility will help facilitate the Hybrid Cloud architecture discussed above. I have already blogged about Azure Stack and why I feel that it is so important so I will not go into that in detail here. See this bog post: The Future of Azure is Azure Stack.

We also should distinguish between true Hybrid Cloud and an IT Hybrid Infrastructure In the case of the latter the resources in the data center need not be in the form of a Private Cloud as discussed above. Microsoft is the clear leader in this space now because of its traditional enterprise data center presence and it’s leadership in converting itself to be a Cloud Company.

So, don’t be fooled by Cloud Pretenders. Apply the NIST litmus test.

Bill Zack

Posted in Architecture, Cloud, Cloud Computing, Windows Azure | Tagged , | Leave a comment

The Nashville Microsoft Azure 2017 Bootcamp

Those of you who know me know that I am also the Founder and President of the Nashville Microsoft Azure Users Group.  This group has grown from four members four years ago to 563 members today. In fact, the group has doubled in size in just the last year alone. This is a testimonial to how Azure is catching on here in Nashville, and globally.

And speaking of globally, we just held our annual Global Azure Bootcamp Event all day Saturday April 22nd in conjunction with Azure groups all over the world.

Keynote

On torrentially rainy day in Nashville, with a flood watch in effect, we had 40 attendees out of the 77 that signed up for our event. Not a bad turnout for a rainy all-day Saturday event.  Smile  We will be doing a satisfaction survey soon, but all the informal feedback was positive, even effusive. We even picked up 14 new members for the group as a result.

We had 12 sessions in two simultaneous tracks, including 4 presenters from Microsoft.

Topics included:

  • Microsoft Cloud Vision and Roadmap (Keynote)
  • Azure Security
  • Backup, High Availability and Business Continuity/Disaster Recovery
  • Operations Management Suite
  • Hybrid Networking Services
  • Citrix on Azure
  • Azure Storage
  • Azure Compute
  • Infrastructure as a Service (IaaS) and the Azure Resource Manager
  • Azure Stack
  • Azure Service Fabric
  • Azure Container Service

I did the talks on Operations Management Suite and Azure Stack.Smile

Alert Logic provided an excellent breakfast from Jason’s Deli. Lunch was provided by Microsoft, and the afternoon break was ice cream provided by Vaco, our perennial refreshments sponsor for the last four years.

The raffle gave away stuff from the global and local sponsors, including two $100 gift cards. There was also SWAG in the form of trial subscriptions of software from the global sponsors. Our thanks to all to our local sponsors, including:

  • Microsoft
  • AlertLogic
  • Vaco
  • Provisions Group
  • Coretek Services

As well as the global sponsors that provided SWAG for the event.

Lots of great photos were taken by Ukela Alred and will be uploaded to the Meetup Site Photos Section/Bootcamp Album shortly.

And a big shout out to Ukela and Scott Schreier who helped with registration and getting folks in and out of the building when the elevators stopped stopping at the 4th floor at Microsoft at  2PM. Smile  Also to Scott for providing those two big agenda posters in front of each meeting room.

We will do this again next year

Bill Zack

Posted in Uncategorized | Leave a comment

Tale of Two Clouds: A Feature Comparison of Azure and AWS

  image

Comparing Azure and AWS is a bit like comparing apples and oranges. Each platform has features that either duplicate or overlap with features of the other platform.

In reality the focus needs to be on solving the business problem and not the technology problem. That being said a lot of companies either have both platforms or are struggling with deciding on, or moving from, one or the other.

Last night at the Nashville Microsoft Azure Users Group I presented a technical comparison of Azure and AWS features.

Despite my admitted bias towards Azure I nevertheless believe that I was pretty fair and objective. Smile

  The topics I covered were:

– Cloud Service Models
– Deployment, Management and Automation
– Compute
– Storage
– Messaging
– Email
– Networking
– Security and Identity
– Operating System & Data Transfer
– Internet of Things (IoT)
– Development Languages and Runtime Support
– Marketplaces
– Media Services
– Mobile Services
– Visualization
– Machine Learning
– Non-Technical Considerations
– Pricing Models

The deck from that presentation is in the files section of the Nashville Microsoft Azure Users Group.

Bill

Posted in Amazon Web Services, Cloud Computing, Microsoft Azure, Windows Azure | Tagged , | 1 Comment