PaaS & Cloud-Native Technologies

If you have worked with Azure for a while, you’re aware of the benefits of PaaS, such as the ability to have the cloud provider manage the underlying storage and compute infrastructure so you don’t have to worry about things like patching, hardware failures, and capacity management. Another important benefit of PaaS is the rich ecosystem of value-add services like database, identity, and monitoring as a service that can help reduce time to market.

So if PaaS is so cool, why are cloud-native technologies like Kubernetes and Prometheus all the rage these days? In fact, not just Kubernetes and Prometheus, there is a groundswell of related cloud-native projects. Just visit the cloud-native landscape to see for yourself.

Key Benefits of Cloud-Native Architecture

Here are ten reasons why cloud-native architecture is getting so much attention:

  1. Application as a first-class construct — Rather than speak in terms of VMs, storage, firewall rules, etc. cloud-native is about application-specific constructs. Whether it is a Helm chart that defines the blueprint of your application or a service mesh configuration that defines the network in application-specific terms.
  1. Portability — Applications can run on any CNCF certified clouds and on-premises and edge devices. The API surface is exactly the same.
  1. Cost efficiency — By densely packing the application components (or containers) on the underlying cluster, the cost of running an application is significantly more efficient.
  1. Extensibility model — Standards-based extensibility model allows you to tap into innovations offered by the cloud provider of your choice. For instance, using the service catalog and open service broker for Azure, you can package a Kubernetes application with a service like Cosmos DB.
  1. Language agnostic — Cloud-native architecture can support a wide variety of languages and frameworks including .NET, Java, Node etc.
  1. Scale your ops teams — Because the underlying infrastructure is decoupled from the applications, there is greater consistency for lower levels of your infrastructure. This allows your ops team to scale much more efficiently.
  1. Consistent and “decoupled” — In addition to greater consistency at the lower levels of infrastructure, applications developers are exposed to a consistent set of constructs for deploying their applications. For example, Pod, Service Deployment and Job. These constructs remain the same across cloud, on-premises and edge environments. Furthermore, these constructs also help decouple the developers from the underlying layers (Cluster, Kernel and Hardware layers ) shown in the diagram below.decoupling
  1. Declarative Model – Kubernetes, Istio, and other projects are based on a declarative, configuration-based model that support self-healing. This means that any deviation from the “desired state” is automatically “healed” by the underlying system. Declarative models reduce the need for imperative automation scripts that can be expensive to develop and maintain.
  1. Community momentum – As stated earlier, the community momentum behind CNCF is unprecedented. Kubernetes is #1 open source project in terms of contributions. In addition to Kubernetes and Prometheus, there are close to 500 projects that have collectively attracted over $5 B of venture funding! In the latest survey, (August 2018), the use of cloud-native technologies in production has gone up by 200% since Dec 2017.
  1. Ticket to DevOps 2.0 – Cloud-native combines the well-recognized benefits of what is being termed as “DevOps 2.0” that combines hermetically sealed and immutable container images, microservices and continuous deployment. Please refer to the excellent book by Victor Farcic.

Now that we understand the key benefits of cloud-native technologies, let us compare it to a traditional PaaS offering:

Attribute Tradition PaaS Cloud-Native as a Service
Portability Limited Advanced
Application as a first-class construct Limited (application construct limited to the specific PaaS service) Advanced construct including Helm, network and security policies
Managed offering Mature (fully managed) Maturing (some aspects of the cluster management currently require attention)
Stateful applications Advanced capabilities offered by the database as service offerings Some cloud-native support for stateful applications (However, cloud-native applications can be integrated with PaaS database offerings through the service catalog)
Extensibility Limited Advanced (extensibility includes Container Network Interface, Container Runtime Interface)

Azure & CNCF

Fortunately, Microsoft has been a strong supporter of CNCF, as they joined CNCF back in 2017 as a platinum member. Since then, they have made significant investments in a CNCF-compliant offering in the form of Azure Kubernetes Service (AKS). AKS combines the aforementioned benefits of a cloud-native computing with a fully managed offering – think of AKS as a PaaS solution that is also CNCF compliant.

Additionally, AKS addresses enterprise requirements such as compliance standards, integration with capabilities like Azure AD, Key Vault, Azure Files etc. Finally, offerings like Azure Dev Spaces and Azure DevOps greatly enhance the CI/ CD experience in working with cloud-native applications. I will be remiss not to talk about VS Code extension for Kubernetes that also brings a useful tooling to the mix.

Cloud-Native Use Cases

Here are few key use cases for cloud-native applications. Microservices are something you would expect, of course.  Customers are also being used to run Apache Spark on AKS.  There is also thinking around managing IoT Edge deployments right from within the Kubernetes environment. Finally, “Lift and shift to containers” – this use case is getting a lot of attention from customers as the preferred route for moving on-premises applications to the cloud. Please refer to our recent blog post on this very topic “A “Modernize-by-Shifting” App Modernization Approach” for more details!

Cloud-Native Scenarios

FREE HALF DAY SESSION: APP MODERNIZATION APPROACHES & BEST PRACTICES
Transform your business into a modern enterprise that engages customers, supports innovation, and has a competitive advantage, all while cutting costs with cloud-based app modernization.

Last week we laid out some basics of what we call the “Full PaaS” approach to legacy app modernization. While it might not make sense in every situation, we recently completed a modernization effort using the Full PaaS approach. Here’s some background and the steps we took…

Stop Playing Legacy App “Whack-a-Mole” 

Our enterprise customer developed and owned a budgeting application. The application was over five years old and built on tech that — while modern at the time — had become “stale” over the years.  Usage patterns for the application included huge spikes in demand during specific times of the year, and the need to meet these demands prompted the team to “reactively” invest in servers with more memory, better networking equipment, and other fixes. Problems were only addressed as they cropped up, with no time for long-term planning.

Yet despite throwing money and equipment at those problems, the issues with the platform continued, while customers were demanding more functionality. Unfortunately, since most of the application team’s time was spent reacting to operating issues, that simply couldn’t happen. Additionally, the application team’s O&M budget shrank over time, leaving a smaller staff responsible for the application.

After analyzing the application, we determined that three tiers of the application (compute, cache, database) could be moved to the “as-a-service” model with a reasonable amount of refactor, for two main reasons:

  • This model would address the seasonal demand challenges by leveraging “auto-scaling” capabilities built directly into the services the application would now be consuming.
  • As an added benefit, these services allowed scripted deployments, automated monitoring, and easier provisioning of “test” environments to get new features in the hands of users more quickly.

The 7 Steps to “Full-PaaS” Modernization

Once we chose the Full PaaS approach, we completed the modernization effort by following these seven (high level) steps:

  1. Analyze application dependencies: This includes compute and data tiers, software architecture, reliance on existing resources.
  2. Identify services to replace legacy components: Not everything will port directly, so map out your replacements ahead of time.
  3. Establish candidate PaaS architecture: Choose your cloud platform, specific services to be used, and architect the flow of communication between the services.
  4. Validate with internal stakeholders: We talk to everyone from operations staff to security to business users of the application.
  5. Refactor your application code: Target the PaaS services included in the candidate architecture.
  6. Automate your application delivery and integrate CI/CD: This is one of the biggest benefits to this modernization approach, so take full advantage of it!
  7. Establish a living roadmap for ongoing improvement: We’re looking for both ongoing improvements to delivery automation and for any additional applications that can also adopt the model.

FREE HALF DAY SESSION: APP MODERNIZATION APPROACHES & BEST PRACTICES
Transform your business into a modern enterprise that engages customers, supports innovation, and has a competitive advantage, all while cutting costs with cloud-based app modernization.

If you’re looking to modernize a legacy application, there are quite a few paths and approaches to choose from. Today, let’s look at “Full PaaS” modernization, which re-architects legacy applications to target cloud-native “serverless” technologies wherever possible.

This can solve many of the most common challenges organizations face when dealing with legacy applications:

  • The need to provide modern capabilities, innovate faster with limited resources
  • Your existing infrastructure is expensive and difficult to provision, maintain, scale, secure
  • Your existing staff could improve efficiency by focusing on their strengths
  • Your customers expect evolving, innovative functionality that relies on expensive, complex underlying technology

Why “Full PaaS” Modernization Is Different

Going the “Full PaaS” route allows your company to take advantage of the “best of the best” that the public cloud has to offer, including:

  • The responsibility for delivering platform quality shifts from IT staff to industry experts (uptime, security, etc.)
  • Managed offerings for all application components provide peace of mind and zero day-to-day maintenance.
  • You can immediately and automatically leverage the innovation and improvements being applied (almost constantly) to the underlying cloud platform.

Once your application is migrated, you’ll enjoy vastly improved speed, flexibility and agility. Modern PaaS platforms offer opportunities to automate and extend delivery processes as a core feature of the service, which creates a lower barrier to entry to incorporate modern, innovative technology for improvement of your software products.

And of course, we can’t talk about moving applications to the cloud without mentioning the cost savings and lower total cost of ownership. You’ll eliminate significant effort required to build, maintain, and evolve the “foundation” of your application’s infrastructure (servers, networking equipment, monitoring stack, data backup and disaster recovery, etc.). This, in turn, will let you focus your development resources on core competency, avoid inefficiencies related to effort not directly focused on improving the quality of your software products.

Sounds Great! Any Drawbacks? 

Well, yes. There are a few things to consider before taking this approach:

  • More significant application refactor or re-architecture could be required, which can include more significant up-front investment.
  • More potential for vendor lock-in specific to a specific cloud provider than other modernization approaches.
  • Existing staff may need to invest in modernizing existing skillsets and deeply ingrained ideas about “the way things are done” – instead emphasizing “software-defined” principles (networking, automation, monitoring).

This approach targets the highest level of maturity for cloud adoption, where you’re consuming cloud native features as a service to provide all of the building blocks for your application.  This won’t fit right away for all situations, as organizations balance an application’s internal dependencies with the need to modernize.  However, this approach can provide significant benefit for legacy application teams given the right circumstances.

FREE HALF DAY SESSION: APP MODERNIZATION APPROACHES & BEST PRACTICES
Transform your business into a modern enterprise that engages customers, supports innovation, and has a competitive advantage, all while cutting costs with cloud-based app modernization.

So Is “Full PaaS” the Right Approach For Me?

AIS looks for the following characteristics when evaluating this approach:

  • The team is willing to invest a bit more time and money up front to modernize in return for the benefits listed above.
  • The team has significant challenges managing infrastructure which aren’t fully addressed by more basic lift-and-shift or “containerization” app modernization approaches. In many cases this comes from a slow erosion of operations and maintenance (O&M) staff over time, leaving developers responsible for all portions of development and delivery.
  • The team is interested in providing evolving features, but is constrained by the lack of innovation on the current platform.
  • The team releases updates/features too infrequently and is under pressure to improve the “cycle time.”

Next week, we’ll take a look at the specific steps involved in the “Full PaaS” modernization approach, and share an example of a successful legacy app modernization project the AIS Team recently completed.

Microsoft Power Platform: Application Development Platform for General Purpose Business Apps

In recent years, with the transition to the cloud, SharePoint teams’ recommendation has been to move custom functionality “down” to the client computer or “over” to a host outside of SharePoint. This change has had a direct impact on enterprises that have long viewed SharePoint as an application development platform.

Today’s best practices show that a grouping of applications, such as case management apps, inventory or issue tracking, and fleet management (depicted in the dotted area of the diagram below) is no longer best suited to be built on top of SharePoint. This is where Microsoft Power Platform comes in for cross-platform app development.

Microsoft Power Platform as an app development platform

What is the Microsoft Power Platform (MPP)?

Microsoft Power Platform (or MPP) is being seen as the aPaaS layer that nicely complements mature Azure IaaS and PaaS offerings. Here are a few reasons we’re excited about MPP:

  • It offers a low-code/no code solution for rapid application development
  • The PowerApps component supports cross-platform app development for mobile and responsive web application solutions
  • Flow within MPP also offers a workflow and rules capability for implementing business processes
  • CDS offers a service for storing business objects

SharePoint as an App Development Platform

On January 30, 2007, we released a paper called “SharePoint as an Application Development Platform” to coincide with the release of Microsoft Office SharePoint Server 2007 or MOSS. We didn’t have the slightest expectation that this paper would be downloaded over half a million times from our website.

Based on the broad themes outlined in this paper, we went on to develop several enterprise-grade applications on the SharePoint platform for commercial as well as public sector enterprises. Of course, anyone who participated in SharePoint development in 2007 and onwards can vouch for the excitement around the amazing adoption of SharePoint.

Features, Add-Ins or “Apps,” and More

A few years later, SharePoint 2010 was announced with even more features that aligned with the application development platform theme. In 2013, the SharePoint team went on to add the notion of apps (now called add-ins) – we even wrote a book on SharePoint Apps. The most recent version of SharePoint is 2019 and it continues the tradition of adding new development capabilities.

All the Ingredients for Unprecedented Success

If you look back, it is easy to see why SharePoint was so successful. SharePoint was probably the first platform that balanced self-service capabilities with IT governance. Even though the underlying SharePoint infrastructure was governed by IT, business users could provision websites, document libraries, lists, and more in a self-service manner.

Compare this to the alternative at that time, which was to develop an ASP.NET application from scratch and then having to worry about operationalizing it including backup, recovery, high availability, etc. Not to mention the content and data silo that may result from yet another application being added to the portfolio.

Furthermore, the “Out of the Box” (OOTB) SharePoint applications constructs including lists, libraries, sites, web parts, structured and unstructured content, granular permissions, and workflows allowed developers to build applications in a productive manner.

With all these ingredients for success, SharePoint went on to become an enterprise platform of choice with close to 200 million licenses sold and, in the process, creating a ten-billion-dollar economy.

By 2013, Signs of Strain Emerged for SharePoint as an App Development Platform

With the transition to the cloud and lessons learned from early design choices, weaknesses in SharePoint as an app development platform started to show. Here are some examples:

  • Limitations around structured data – Storing large lists has always been challenging, despite the improvements over the years to increased scalability targets for lists. Combine scalability challenges with the query limitations and it makes for a less than ideal construct for general-purpose business application development.
  • Isolation limitations – SharePoint was not designed with isolation models for custom code. As a result, SharePoint farm solutions that run as full-trust solutions on the server side have fallen out of favor. The introduction of sandbox mode didn’t help since isolation/multi-tenancy was not baked in the original SharePoint design. The current recommendation is to build customizations as add-ins that run on the client side or on an external system.
  • External data integration challenges – BDC (Business Data Services) was designed to bring data from external systems into SharePoint. Business Connectivity Services (BCS) extensibility model was designed to allow an ecosystem of third-party and custom connectors to be built. But BCS never gained significant adoption with limited third-party support. Furthermore, BCS is restricted in the online model.
  • Workflow limitations – Workflows inside SharePoint are based on Windows Workflow Foundation (WF). WF was designed before the REST and HTTP became the lingua franca of integration over the web. As a result, even though SharePoint-based workflows work well for a document-centric workflow like approval, they are limited when it comes to integrating with external systems. Additionally, the combination of WF and SharePoint has not been the easiest thing to debug.
  • Lack of native mobile support – SharePoint was not designed for mobile experiences from the ground up. Over the years, SharePoint has improved the mobile experience through the support for device channels. Device channels allow for selection of different master pages and style sheets based on the target device. But device support is limited to publishing pages and even those require non-trivial work to get right. In a mobile-first world, a platform built with mobile in mind is going to be the ideal cross-platform app development tool for enterprises.
  • Access Services (and other similar services) never took off – Access databases are quintessential examples of DIY Line of Business (LOB) Apps. So when SharePoint 2010 introduced a capability to publish Access databases to SharePoint, it sought to offer the best of both worlds, self-service combined with governance (the latter being the bane of access databases). However, that goal proved too good to be true and Access Services never caught on and are now being deprecated.
  • Development “cliffs” – SharePoint was supposed to enable business users to build their own customizations through tools like Visio and SharePoint designer. The idea was that business users would be able to build customizations themselves using SharePoint designer and if they ran into a limitation (or the “cliff”), they could export their artifacts into a professional development tool like Visual Studio. In reality, this dichotomy of tools never worked and you almost always had to start over.
  • State of art in-low / no-code development – If you look at leading high-productivity application development platforms, the state of art seems to be around a declarative model-driven application approach. In other words, using a drag and drop UI, a user can generate a metadata-based configuration that describes the application, flow of application pages, etc. At runtime, the underlying platform interprets this configuration and binds the actions to the built-in database. SharePoint obviously has a rich history of offering no-code solutions, but it is not based on a consistent and common data model and scripting language.
  • Monolith versus micro-services – In many ways, SharePoint has become a “monolith” with tons of features packed into one product — content management, records management, business process, media streaming, app pages — you name it. Like all monoliths, it may make sense to break the functionality into “micro” services.

Note: With all the challenges listed above, SharePoint as a collaboration software continues to grow. In fact, it’s stronger than ever, especially when it comes to building collaboration-centric apps and solutions using the SharePoint framework and add-ins.

Just visit the thriving open source-based development centered around SharePoint Development to see for yourself.

Enter the Microsoft Power Platform (MPP)

The below diagram depicts a high-level view of the Microsoft Power Platform (MPP).

Microsoft Power Platform Infrastructure Overview

The “UI” Layer: Power Apps, Power BI, and Flow

At the highest level, you have the Power Apps, Power BI, and Flow tools.

Power Apps is a low-code platform as a service (PaaS) solution that allows for business app development with very little code. These apps can be built with drag and drop UI elements that work across mobile, tablet, and web form factors. In addition to the visual elements, there’s an Excel-like language called PowerApps Expression Language that’s designed to implement lightweight business logic and binding visual controls to data. Since PowerApps comes with a player for Android and iPhone devices, it doesn’t need to be published or downloaded from app stores.

Additionally, admin functions like publication, versioning, and deployment environments are baked into the PowerApps service. The PaaS solution can be used to build two types of apps:

  1. Canvas apps – as the name suggests, these allow you to start with a canvas and build a highly-tailored app.
  2. Model-driven apps – also as the name suggests, these allow you to auto-generate an app based on a “model” – business and core processes.

You’re likely already familiar with Power BI. It’s a business analytics as a service offering that allows you to create rich and interactive visualizations of sources of data.

Flow is a Platform as a Service (PaaS) capability that allows you to quickly implement business workflows that connect various apps and services.

Working together, PowerApps, Flow and Power BI allow for business users to easily and seamlessly build the UI, business process, and BI visualizations of a cross-platform, responsive business application. These services are integrated together to make the experience even better. As an example, you can embed a Canvas PowerApp inside of Power BI or vice versa.

The “Datastore and Business Rules” Layer

Common Database Service (CDS) allows you to securely store and manage data used by business applications. In contrast to a Database as a service offering like Azure SQL Database, think of CDS as a “business objects as a service”. Azure SQL Database removes the need for physical aspects of the database but as a consumer of Azure SQL, you’re still required to own the logical aspects of the data, such as schema, indexing and query optimization, and permissions.

In CDS all you do is define your business entities and their relationships. All logical and physical aspects of the database are managed for you. In addition, you get auditing, field level security, OData API, and rich metadata for free.

Finally, CDS offers a place to host “server-side” business rules in the form of actions and workflows. It’s important to note that CDS is powered by Dynamics CRM under the covers (see [1] for more information on this). This means that any skills and assets that your team has around Dynamics will seamlessly transition to CDS.

“External Systems Connector” Layer

PowerApps comes with a large collection of connectors that allow you to connect with a wide array of third-party applications and services (like SalesForce and Work Day) and bind the data to PowerApps visual controls. In addition, you can also connect to a custom app of service via Azure API Management and Functions.

How Can MPP Alleviate SharePoint Development Challenges?

MPP is a platform designed from the ground up for building business apps. Here’s how it can help alleviate the challenges users may experience with SharePoint as an app development platform.

Challenge SharePoint as a dev platform Power Platform
Structured Data Limits of items, throttling, and queries Backed by a fully relational model
Isolation No server-side isolation model. Server-based farm solutions are discouraged. Each tenant is isolated and allows for running custom code
External Data Integration BCS – limited third-party support 230+ connectors
Workflow Limitations Document-centric workflow HTTP REST based scalable workflow construct that can leverage OOTB connectors
Mobile Support Limited support in the form of device channels Designed from the ground up for mobile support
Development “Cliffs” Hard to transition from citizen dev to prod dev tools There a single tool for citizen developers and pro dev users. Pro dev users have the ability to use the extensibility to call Azure Functions, Logics Apps etc. for richer and complex functionality.
Low Code Development No common domain model or scripting language Designed from the ground-up as a low code development environment.
Monolith vs micro-services-based approach Monolith Comprised of a collection of “micro” services PowerApps, Flow, Power BI, CDS

Comparing Reference Architectures

The following diagram compares the SharePoint and MPP reference architectures.

SharePoint and MPP Reference Architectures Compared

Power Platform Components Inside SharePoint?

It’s noteworthy that advancements in MPP are available in SharePoint. For example, “standalone” Canvas PowerApps and Flow integrate directly into SharePoint are shown in the table below.

In many ways, this development represents a realignment of SharePoint’s place in the application development space. We believe that MPP is the new “hub”, while SharePoint (and other Office 365 components) represent “spokes” in this model.

PowerApps as a “custom form” for a SharePoint list item.

PowerApps as a custom form for a SharePoint list item example

Flow powering a document-centric workflow

Flow powering a document-centric workflow example

Consider MPP for Your Next Business App Development Project

The Microsoft Power Platform is an aPaaS offering that’s designed from the ground up as a general-purpose business application development platform, which includes native mobile support, first-class low-code environment, business data as a service, a lightweight workflow engine, and rich business analytics all in one. We believe that a category of applications, that were previously built on SharePoint will benefit in moving to the Microsoft Power Platform.

[1] xRM with Dynamics CRM

xRM style applications have been built on Dynamics CRM for years. Unfortunately, the licensing story to support this model was not ideal. For example, customers could not license a “base” version without paying for sales, marketing functionality built OOB.

That’s all changing with CDS. PowerApps licenses, such as P1 and P2, give customers access to what’s referred to as “Application Common” or Base instance of CDS.

CDS Apps Instance vs Dynamics Instance

Learn More About MPP & Your App Development Platform Options

The road to general-purpose business application development can be challenging to navigate with all of the tools and platforms available, as well as the unique pros and cons of each option. Not sure where to start? Start with a conversation!

START THE CONVERSATION
See if MPP is a good fit for your orgs app development needs. Contact your partner at AIS today!

I put together a two-part video presentation on how (and why!) to take on-premises applications and move them to the cloud (specifically the Azure PaaS platform), and how to do it quickly.

The second video continues the process and covers app modernization with Service Fabric.

FREE HALF DAY SESSION: APP MODERNIZATION APPROACHES & BEST PRACTICES
Transform your business into a modern enterprise that engages customers, supports innovation, and has a competitive advantage, all while cutting costs with cloud-based app modernization.

I am pleased to announce my latest Pluralsight course on PowerApps (Well…such is the nature of change in the cloud that there has already been a name change since I submitted this course for publication, only a few weeks back. The aspect of PowerApps covered in my course is now referred to as Canvas Apps.)

This course is designed for developers (both citizen and professional developers) interested in a low-code approach for building mobile applications.

Here’s some background on PowerApps, if you haven’t had a chance to play with it yet:

PowerApps is a productive low-code development platform. It allows you to very quickly build business applications that can run inside a web browser, on a phone or a tablet. PowerApps includes a web-based IDE (PowerApps Studio, a set of built-in cross-platform controls), an Excel-like expression language that also includes imperative constructs like variables and loops, and over 130 connectors to talk to any number of data sources — including SQL Server, Office 365, Salesforce, Twitter, etc. You can also use custom connectors to talk to your domain-specific data source.

Beyond the controls, language expression and connectors, PowerApps provides ALM support in the form of app versioning, app publication to various app stores, swim-lanes for development environments, authentication and authorization (via Azure AD), RBAC controls, and security polices like data loss prevention (DLP).  All in all, the PowerApps service seeks to significantly lower the bar for building and distributing cross-platform mobile applications within your enterprise.

For a concrete example of our use of PowerApps, please read how we built a cross-platform event app in less than a week. Also please check out a recent episode of DotNetRocks where we talk about PowerApps.

Finally, as part of the latest spring update, PowerApps is combining with Dynamics 365 for Sales, Marketing, and Talent applications to offer an enterprise high-productivity application platform as a service (known as Microsoft Business Applications platform). What this means for PowerApps developers is that:

  1. They can now take advantage of server-side logic
  2. They have access to a data-centric way of building declarative apps, known as model-driven apps (in contrast to canvas apps, which are built by dragging and dropping controls to a canvas).

For more information on the spring update, please refer to this blog post by Frank Weigel.

I hope you will find this course useful. Please reach out to me via this blog or Twitter if you have any questions or comments.

The Microsoft Government Tech Summit – a free, technical learning event for IT professionals and developers – is coming to Washington D.C., March 5-6, 2018! This two-day event will be packed with technical content, and this year Microsoft is showcasing Azure Government and Microsoft 365 for US Government.

Our Cloud Application Development Director, Brent Wodicka, is presenting this year on “A PaaS-First Approach to DoD Mission Apps” on March 5th at 1 p.m.  He will be co-presenting with Microsoft’s Derek Strausbaugh, and showcasing how Azure simplifies and re-imagines legacy mission applications. Registration is now open, and we’re hoping you can join us!

As the expectations of citizens increase, the need for technology innovation in government intensifies. Learn how cloud innovation can help meet the needs of the nation. Whether you’re interested in learning about security approaches or attracting and retaining talent with a more flexible and modern workstyle, Microsoft Government Tech Summit can help you evolve your skills and deepen your expertise to lead your agency through digital transformation.

What to expect:

  • Connect with experts from Microsoft and the community, and learn how to get the most from the cloud. Ask your toughest questions, learn best practices, and share strategies.
  • Choose from a variety of learning opportunities to deepen your cloud expertise, from keynotes and breakout sessions, to hands-on labs and a hackathon.
  • Customize your learning – whether you’re already cloud-savvy or just getting started – Microsoft Government Tech Summit has something for everyone.
  • Discover the latest trends, tools, and product roadmaps at more than 60 sessions covering a range of topics, including over 40 sessions focused on the needs of government agencies.

The cloud is changing expectations – and transforming the way we live and work. Join us at the Microsoft Government Tech Summit and learn how Microsoft’s cloud platform can help you lead your agency through digital transformation – and make the cloud part of your mission success.

REGISTER NOW

2017 was another great year overall here at AIS, and also marked the fifth anniversary of our blog! We hope you enjoyed reading and found our posts helpful and interesting. We’re all pretty passionate about what we do here, and look forward to sharing more thoughts, insights and solutions in 2018 and beyond!

As we close out the year, here are the top 10 most read and shared blog posts of 2017:

1) Office 365 Groups vs. Microsoft Teams by Jason Storch

2) Lift & Shift: Migrating Legacy Applications to Azure Cloud by Nasir Mirza

3) Dockerization of Azure PaaS (Beyond Azure Container) by Vishwas Lele

4) Managed Images in Azure (Create & Deploy) by Justin Baca

5) Building Stateless Microservice Using Microsoft Service Fabric Series by Kasi Srinivasan

6) Azure PaaS Options: When to Use What? by Vishwas Lele

7) A three-way tie (!) for Parts One, Two & Three of Automated Deployments with Azure Resource Manager Templates, Azure Automation, & Octopus Deploy by Harun Davood

8) It’s Time to Review the Failure Modes of Your #cloud App(s) by Vishwas Lele

9) Pattern Matching vs. Deep Learning by Vishwas Lele

10) A Fix for the SharePoint Search Query/Result Mismatch by Clint Richardson

Happy New Year to all our readers and bloggers! Be sure to follow AIS on Twitter, Facebook or LinkedIn so you’ll never miss a post.

As 2017 ends, it’s clear that while the enterprises (public sector and commercial) are increasingly moving to the public cloud, they face significant challenges. Earlier in the year, I wrote about bridging the chasm between the expectations from an enterprise regarding cloud capabilities and the actual out-of-the box features offered by cloud providers. Additional challenges include the foundational culture shift to cloud governance, DevOps and automation, security and compliance, and mapping an enterprise’s application portfolio to a complex array of cloud service options.

Here are five things you can do next year to better assist enterprises adopt the public cloud: Read More…