DevOps and Why You Need a Managed Code Team

Cloud Computing is complex.

I have focused on cloud computing since 2007, nearly 10 years.  I write a lot of code myself for Azure Cloud and I also pay the bills giving me a real perspective.  Whoever told you or intimated that cloud computing would make your life easier as a developer, ISV, systems integrator, failed to tell you the truth.

My company Intact, is dedicated to your success. Cloud is not easy.  Read on to learn more…

If you want or expect to have it easy in a cloud world then you need to use “Software as a Service” (SaaS) apps where somebody else owns, maintains, and supports your IT needs.

If you are an IT Pro, developer, or IT manager that has mission critical applications that you support for your customers and you are already “saturated” at the team level then expect a long day when shifting to cloud.

EDIT: Azure has more than 50 individual services and growing.  There are at least 5 different ways to configure each of the majority of those.  That means that there are more than 5 million combinations to configure Azure.

Cloud over the past ten years has expanded exponentially in its service offerings.  The number of different items to contend with in porting workloads, developing new services, and maintaining control simply overwhelms whole teams.  I wrote several years ago, “No jobs would be lost due to cloud.  The jobs would change and the responsibility would change but it will still require people with new skills to run cloud applications.”

My friend (let’s call him Joe), is an IT Pro and manager who wants to learn cloud computing for his team.  I admire Joe for his desire to make the transition.  Joe’s problem is the team skills deficit in general.  Joe desires to learn cloud and implement it as he would have past projects.  My company and my team are immersed 100% in Azure Cloud.  We don’t do AWS or any other cloud for a very simple reason.  Being an expert means focusing on one thing.  Intact is focused on business applications for Azure Cloud – nothing else.  Believe me when I tell you, there are too many moving parts to cloud to think that you can “tinker” with it.  Obsolesces is measured in months not years.  You must have a continuous integration mindset about your applications.

DevOps – development and operations.  In raw form this means that the developers are responsible for the operation.  In my experience very few teams are configured for this type of computing model.  Currently responsibilities are spread across many different teams: developers, testers, security, administration, release management, maintenance, network, systems and so forth.  I have been in the hundreds of meeting where all the team leads discuss the weekly and monthly issues list.  The structure of organizations is wrong for cloud services.  You still need all of those skills but the “who” is responsible and delivering is completely different.

Intact helps teams through automation reach cloud application maturity in DevOps by supplying the missing skills.

Should you Develop in Access 2016

Should you develop or reengineer your old Access or FoxPro desktop applications in Access 2016?

NO, has been my answer for the past 10 years for any Access development. Read on for a more through explanation and considerations. Microsoft does not include Access 2016 in any of its Office 365 business packages. HINT!


Access 2016 continues into the age of cloud as an add-on purchase application in Office 365.  But Access 2016 is not the Access that most users think it is.  On the Microsoft site this statement is made:

“Access 2016 has all the functionality and features you’re used to with some added enhancements and the best new features from Office 2016.
Note: For Access 2016, no existing features or functionality from previous versions were deprecated in this release.” https://support.office.com/en-us/article/What-s-new-in-Access-2016-76454345-f85d-47af-ace1-98a456cb3496

This statement is completely true. BUT… as the late Paul Harvey would famously say, “now the rest of the story.”

The very short answer is that prior to Access 2013 to which the statement refers Access has been systematically stripped of functionality.  There have been “new features” added, true.  When Microsoft removed the ability for later versions (2007 >) to open older database structures they introduced “new features” to replace the functions. (see this article: https://en.wikipedia.org/wiki/Microsoft_Access )

So should you develop a new application or reengineer an old one in Access 2016?  The answer is a solid maybe.

I might be oversimplifying some but this should give you some sense of how to approach the problem.

  1. Who is going to be doing the development?
    • Business users
    • Professional developers
  2. Will the resulting project be a critical business application?
  3. Will the database be on a managed SQL Server?
  4. Do you or your organization have any database reporting tools?
  5. Who is responsible for the application maintenance and updates?
    • Business users
    • Professional developers

Generally, if any of the above is answered “Yes” or a developer is expected to be involved then Access is not the way to go.

For line of business applications Access requires the same amount of development effort that any other professional development would require.  Access now requires a per-user subscription and it requires a SQL-Server database subscription or on-premises license.  Yes, SQL-Express license is free.  If you are a professional developer, there are other tools that are very effective for line of business solutions.

Why change if what you have works?
There may be no reason particularly if you upgraded your systems over the years and your current implementation is in Office 2013 and your data is already on a SQL-Server.

As you read this remember Access was developed for Windows desktop computers.  It depended on Windows and plethora of Windows drivers installed on a specific computer to work.  It was not a server application.  In the workplace it was very limited by design to run in a desktop with limited memory and disk-space.

Most Access database implementations are Windows “desktop” applications.  Over the 25-year history of Access it slowly morphed from a database engine with an application frontend for desktop to now just a fancy web site development tool that hooks to a SQL Server.

Up through Access 2007 you could create a database separate from your Access Application.  That was considered a great feature.  Application developers commonly would develop for Windows computers applications in programming languages such as Visual Basic, C/C++, Delphi, and many others.  These applications could use Windows installed drivers to connect to an Access database engine.  In many cases a copy of Access was not required to use the Access database.  During these years many companies sold third-party “controls” made for Windows desktop computers.  Access allows these to also be used in an Access desktop application.  There is a major problem with controls in modern applications, they mostly don’t work anymore.

Microsoft has discontinued many drivers because they do not meet modern security standards and many were targeting Windows desktop clients that are no longer supported such as Windows XP, Windows 7 (at end of life), Windows 8.

If you are moving to Windows 10 then you are very likely to have issues with Access applications or applications that used the Access database engine.  Consider moving to a different platform that is better suited for line of business.

If you have a small application that is not critical to your business, you should seriously consider a cloud software as a service (SaaS).  You get high reliability and professional software maintenance that you don’t have to worry about.

Reporting is the one use of Access that might make sense but only in a limited sense.  The reason is simple; Microsoft is making its Office 365 apps programmable.  Word and Excel are clearly the cornerstones of the Office 365 product line.  Both now have very advanced development API capability that integrates with all Microsoft products.  Access will continue to be part of the Office 365 product line for years to come but its use is quickly becoming a niche market.  The original purpose for which it was created in now a thing of the past, the desktop database.

Summary
I would only recommend Access as a solution for trivial applications, training, or for a very specific needs case.  The number of variations introduced over the years makes understanding what you really have in Access very difficult.  So much of Access was dependent on the specific version of Windows and its installed drivers it is very difficult to predict if it will work in new modern environments.


Below are links to Microsoft documentation to substantiate my assessment.
https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=Access&Filter=FilterNO
https://support.office.com/en-us/article/Discontinued-features-and-modified-functionality-in-Access-2013-BC006FC3-5B48-499E-8C7D-9A2DFEF68E2F
https://support.office.com/en-us/article/Discontinued-features-and-modified-functionality-in-Access-2010-9714e5e4-4bbc-490f-97b6-29a7730381cb
https://blogs.office.com/2010/01/09/access-2010-deprecated-features-and-components/#lLFfIjs5WqsQYiaz.97
https://msdn.microsoft.com/en-us/library/bb203849%28v=office.12%29.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/office/dn602608(v=office.14).aspx
https://msdn.microsoft.com/en-us/library/ms810810.aspx
https://support.microsoft.com/en-us/kb/957570
https://support.microsoft.com/en-us/kb/231943

Deploy .NETCoreApp to Azure Service Fabric

Should be obvious how to do this.

Either it is not obvious or I am really slow (yep, left myself open).  So you can’t wait to use the .NET Core 1.0.x platform and you are a glutton for punishment like me.  You want to get your brand new .NETCoreApps up on Azure Service Fabric.  Well it is not exactly clear how to do this and the Visual Studio templates don’t help here.

Note: Visual Studio 2015 Update 3 with latest tooling as of this post date do have an ASP.NET Core template for Azure Service Fabric.  But ASP.NET Core is not a .NETCoreApp.

Why do you want to do this? In my case, my company has been steadily porting our aging .NET Framework libraries to the new .NET Core.  I do not want to go back to the old .NET Frameworks.  Microsoft just informed we developers about the new .NET Standard 2.0 here.  If you were around back in the late 1990’s and very early 2000’s you likely struggled with the transition from ASP Classic to .NET 1.0/1.1.  If that wasn’t enough .NET 2.0 quickly followed.  There was no direct port from the 1.1 to 2.0 back then.  It seems that we should have learned by now that 1.x anything is just a trial run.  So we all have deja vu with .NET Standard 2.0.  Yeah this time its going to be better…  My fingers are crossed.

The Nitty Gritty

So I promised to tell you how to deploy your .NETCoreApp to Azure Service Fabric.  The first thing to know is this is a “guest executable” in service fabric. Read this article for background here “Deploy a Guest Executable to Service Fabric”.  I expect that you have a working .NETCoreApp that you want to run in Azure Service Fabric ready and tested locally.  The best way to do the deployment is to use Visual Studio as the article describes.  But you must do a little prep-work first for the .NETCoreApp to make it work.

It is utterly simple. In Visual Studio with your desired .NETCoreApp, right-click the project.  From the context menu click “Publish…” and use “File System” as the target location.  Make a note where you put your output.  The default is bin/release.  This causes Visual Studio to gather all the files necessary to run your application into a single folder.  The current Visual Studio tooling does not do this for .NETCoreApp when publishing to the fabric.

Now that you have a complete package you are ready to create your Azure Service Fabric guest executable.  From Visual Studio create a new Service Fabric project and select the guest executable template.  A configuration dialog appears. In the required Code Package input field browse to the folder discussed above and select it.  If you are still developing your .NETCoreApp select the “link” to your code and also choose “CodeBase” for your work folder. From here you publish your .NETCoreApp to your Azure Service Fabric (cloud or local).

Parting Shots:

If you are still developing your .NETCoreApp you will have to repeat the publish cycle every time you want to test in the fabric.

The clue to the problem was found in the Microsoft documentation article mentioned above.  The tip off was this statement:

Service Fabric does an xcopy of the content of the application root directory…

That simple statement and the word “xcopy”.  The ah-ha! moment.  All the reference libraries are not present in the bin folder!  Visual Studio keeps all the standard libraries in a common location on the local computer.

I hope this saves you a bunch of time.

Cloud Business and Florida Hurricane Hermine

Eleven (11) years since the last hurricane hits Florida!  My company, Intact Partners, is an “all-in” cloud business.  Office 365 Enterprise, Microsoft Azure, and Visual Studio Online (TFS) its business as usual, almost.  The “almost” is just related to the fact that employees are working from their homes using Skype for Business.  All of our work, applications, and files are safely stored away on the cloud.  We haven’t missed a beat!

So last night hurricane Hermine rolled into Tallahassee, Florida.  We lost power at our house at 1:32 AM. No electrical power, no cable, and no Internet. (No Internet is caused by the wide area power outage taking down backbone services.)  No worries here.  The backup generator is powering the house, Windows Phone is providing Internet service and my Surface Pro 3 is providing all my normal services.  Business as usual for Intact Partners.

When you think you business continuity is better in your local datacenter, my experience says you are wrong!  This in not the first time I have experienced Microsoft Azure coming through in a hurricane.  When I was CIO at Florida Department of State during the 2012 presidential election I had moved the election system to Azure.  Hurricane Sandy rolled over Virginia where one of the Azure datacenters is located.  It happened on the first day of early voting in Florida that year.  To prove the disaster recovery ability of the system we constructed on Azure I “failed-over” our service from the San Antonio Azure center to the Virginia center just after Sandy.  Florida’s election 2012 was run on our Azure disaster site and was a total success.

This morning as I compose this blog, I am at home with my family as are my employees are with theirs, not worried about business interruptions for my company and more importantly I am not fretting about my customers.  Their services are safely and securely operating in Azure.  The people I am praying for this morning are the more than 100 thousand people without power and the crews working hard to restore power and save lives.  I will continue to pray for those who are still in the path of Hermine as it rolls on north up the east coast today.

Larry Aultman, CEO
Intact Partners

Been a Long Absence

Building my company has consumed so much time I have neglected my blog.  I am sure that it will take some time to get back into the habit so please follow me.

It has been nearly four years since I last blogged and a lot has happened in my life personally and professionally.  The personal side is best left to Facebook.  My professional profile is maintained on LinkedIn and my company can be found here.

I have not totally be silent while not blogging.  On the company site under the Solutions menu you can find my whitepapers.

I plan to talk about business topics related to Microsoft Azure and the new .NET Core development platform.

So please come back often for my thoughts and opinions about cloud computing.

Thanks,

Larry