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.

A variety of screens displaying Power Platform capabilities
Microsoft recently released a lot of new capabilities in their business applications, including the Microsoft Power Platform, which combines Flow, Power BI, Power Apps, the Common Data Service for apps, and Dynamics 365. To help people gain insights into the power of these applications, the Microsoft Technology Center in Reston, VA offered a Microsoft Business Applications Workshop for Federal Government, which I attended with two AIS colleagues.

As a User Experience (UX) Researcher who joined AIS earlier this year, I am new to Microsoft business applications. In addition, code writing is not my job responsibility and expertise, unlike my two colleagues. However, I found the workshop intriguing and registered for it right away because it was designed to:

  • Help people gain an understanding of the business applications
  • Be “interactive,” with hands-on opportunity for attendees to build a working application
  • Include topics like “solution envisioning and planning” and “no-code business workflow deployment” (Note that the workshop did offer coding exercises for developers on the last day of the workshop, which I did not attend.)

Indeed, attending the workshop allowed me to see the possibilities of these Microsoft applications, which is very relevant to what I do as a UX Researcher. It motivated me to further explore resources on this topic to better meet the needs of our current and future clients.

The User-Centered Design Process

The first project that I worked on after joining AIS was to help a client understand their employees’ needs and collect user requirements for a new intranet to be built on Office 365. In addition, the key stakeholders wanted to:

  • Streamline and automate their business processes, workflows, and document management
  • Drive overall collaboration and communication within the organization

I had extensive experience conducting user research for websites and web applications. To collect employee insights for this new intranet, we followed a user-centered design process:

  1. We started by interviewing stakeholders, content owners, and general employees to understand:
    • Their existing intranet use, areas that worked well, and areas that needed to improve
    • Intranet content that is important to them
    • Existing business processes, workflows, document management, internal collaboration, and communication
  2. Based on the interview findings, we then:
    • Compiled a list of important content pieces that the new intranet should include
    • Set up an online card sorting study for the employees to participate to inform the information architecture (IA) of the new intranet
    • Documented employees’ needs and expectations in other business areas
  3. Proposed a draft IA for the new intranet based on card sorting findings
  4. Developed a wireframe intranet prototype (using Axure), which reflected the draft IA, contained employee desired content, and mimicked the Office 365 structure and capabilities
  5. Conducted remote usability testing sessions with stakeholders and general employees to evaluate the wireframe prototype
  6. Finalized the intranet prototype and documented UX findings and recommendations to help developers build the new intranet using Office 365 in the next phase

As shown above, we made sure that the Intranet would meet the needs and expectations of the stakeholders and general employees, before it was coded and developed. However, as a UX researcher who does not code, I did not develop our solutions using the Microsoft business applications. I was curious to see how my technical colleagues would apply the capabilities of these applications to improve, streamline, and automate business processes and workflows.

Our user research showed that employees experienced a lot of frustration and pain points during their daily work. For example, both managers and general employees complained that their business processes heavily relied on emails, email attachments, and even hand-written notes, which were easy to miss or misplace and hard to locate. They described how difficult it was for them to keep track of project progresses and updates, especially when people from multiple departments were involved. Some of them also mentioned they had to manually enter or re-enter data during a workflow, which was error-prone. All these were real and common business process problems.

The Power of the Power Platform

This workshop provided me with a starting point and a glimpse into the power of the business applications. I’m still learning about their full power, the technical descriptions or details, and the rationale or logic behind each step that we went through when we built the model-driven app during the workshop. However, I was excited to walk away knowing about:

  • The use of a single, connected, and secure application platform to help organizations break down silos and improve their business outcomes
  • The availability of hundreds of out-of-box templates, connectors, and apps, including those that our client can take advantage of and easily customize, such as for onboarding tasks, leave requests, expense reimbursements, and shout-outs to co-workers
  • Building solutions and applications quickly and easily with simple drag-and-drop user interface, without the need to write a single line of code
  • Higher work efficiency of business people and non-developers to achieve what they want to do independently, relying less on IT support or developers, reducing overall cost, and saving time

After the workshop, I found a wealth of online resources and videos on Microsoft Business Applications. Below are some Microsoft webpages that describe the similar content or steps that we went through during the workshop:

I look forward to more in-depth learning about this topic to better understand the power of Microsoft business applications. With this knowledge and together with my colleagues, we will propose and build the best business solutions based on user research, helping our clients achieve desired outcomes by improving their employee experience.

If you didn’t catch the first part of this series, you can read that here.  In this part, things should get a little more interesting as we set up a PowerApp and our SharePoint site.

Objectives

  1. Create SharePoint Online Team Site.
  2. Create a PowerApp for team members to collect data with.
  3. Embed this PowerApp into a SharePoint page so we can do more work in a single environment.

Creating Our SharePoint Team Site

Using our existing SharePoint Online instance, I’m going to create a new Team site off of the root site collection.

  1. From the home page of the root site collection, click the “Create site” button.

Create site screenshot

2. Select Team site on the panel that opens.

Create a Site screen with Team Site hightlighted3. Fill in the information on the next page and click Next.

Team Site information input page

4. Add any additional users and click Finish.

Add additional users screenshot

If all went well, you should be redirected to the new site.

Screenshot of new Team Site

Creating the PowerApp

To be clear, we are going to create a “canvas” PowerApp as opposed to a model-driven PowerApp.  To get this going I’ll navigate to my PowerApps environment and create a new app.

Screenshot of PowerApps environment

    1. From your PowerApps home page, click Create.
    2. On this page you can see various templates for making both model-driven and canvas apps. We’re going to use the “Start from data” Canvas app.Screenshot with Start From Data option highlighted
    3. On the next page we see multiple choices for apps that start with our data. I’m going to use the Common Data Service here.Screenshot with Common Data Service hightlighted
    4. With my Common Data Service account instance selected under “Connections,” I scroll to find and select the “Patches” table, then click “Connect.”

Screenshot of Connections

PRO TIP:  If you get to this point and you still don’t see your data, make sure to check the “Environment” at the top right of the window.  You may not have the correct environment selected where your data is stored.  You can read more about Environments in PowerApps here.
Screenshot with Environments highlighted

        1. Once PowerApps is done creating the new app, the app designer will appear.

      Screenshot of App Designer

Let’s pause and look at this screen for a minute.  On the right, we have our properties and some other items, in the middle we have our design canvas, and on the left we have our Screens Explorer.  In our Screens Explorer we see three screens already created for us: the browse, detail, and edit screens.

If you look under each of those screens you’ll see a primary user interface object that is collapsed (meaning it has content/child nodes underneath it), along with some other user interface elements that usually provide some other functionality or a label.  When you select an element in the Screens Explorer it will also be selected on the design canvas.  In the previous screen shot, the Search Icon is selected under the Browse Screen 1 item.  Consequently, the search hourglass on the design canvas is also selected.

We don’t want to change this up much, but I think we can all agree that it would be a lot more helpful to have something other than the created-on date and item id as our main fields for each row.

PRO TIP:  PowerApps provides us with a super fast way of spinning up apps by automatically building things into our apps like navigation and search controls.  Be careful about changing or removing these unless you plan to replace them with a control of your own that provides the same functionality.  Oftentimes if you remove one of these you render a portion of the app unusable or difficult to access.  To see what a given user interface item does, select it in the designer and check out the “OnSelect” Action in the Advanced tab on the right.

Screenshot with OnSelect option highlighted

      1. Select the bolded date field on the row item on the design canvas and make sure the Advanced tab is selected on the right.
      2. In the Data section under the Advanced tab, we can use the Text field to change what we want displayed in each of these user interface elements. I’m going to change the first to name, the second to city, and the last one to state.Screenshot of text field

Once we’re done tweaking the browser display we’ll want to work on the detail and edit forms.  These work a bit differently.

      1. Select the Detail Form under the Detail Screen node. In the right pane under Properties, select the Fields link that indicates the number of fields currently selected.
      2. Check any fields you would like that aren’t currently on the form. Similarly uncheck any fields the system put on the form that you want to remove.  You can also reorder the fields to your liking.

After a little bit of tweaking to both our detail and edit forms we’re ready to publish this PowerApp.  You can preview the app with the “Play” arrow icon near the top right, or just switch over to your File menu to wrap things up.

      1. Click the File menu and under App Settings give your app a name and feel free to play around with the icon and background color. There are other settings you can explore too but for now we’ll just cover the basics.
      2. Click “Save” to save your app to your gallery.

Screenshot of gallery

In this next screen shot I’ve captured our three screens from left to right: display, detail, and edit. Screenshot of app screens.
You might be wondering what the Generate Advertisement switch is for on the edit screen.  We’ll use that to toggle that specific functionality later in our Flow.

Finally, if you click on the ellipsis for the new app in our PowerApps app gallery, you can click “Details” and get additional helpful information for the app such as the app URL.  This will come in handy for what we do next.

Here are some screen shots from my mobile phone as I helped gather inventory for this massive side project!

Screenshots of app data

Embedding the PowerApp in SharePoint

As mentioned, we don’t want to find ourselves jumping back and forth between application instances for managing inventory.  Thankfully we’re able to embed our PowerApp into the SharePoint page we want so we can do a lot of our common work from that one screen.

      1. Open the SharePoint site we created earlier and edit the home page. I’ve tweaked mine so we only have the Documents Library web part and some empty columns.
      2. Click the plus button in the right column to add a new web part. Find the Microsoft PowerApps web part and select it.Screenshot
      3. Paste the link from your PowerApp into the “App web link or ID” field in the right pane that opens. The app should come up in the new web part.Screenshot
      4. Publish the page.

We can now use the same PowerApp that everyone else will be using on their mobile devices, right here in SharePoint.

Screenshot of PowerApp in SharePoint

Tune in next time, when we’ll use Microsoft Flow to move some data around, automatically generate advertisements, and notify team members of important events.

Part One: Identify, Define, Build, Migrate

An assortment of fire department patchesMy dad passed away in 2015, leaving behind an extensive collection of fire trucks, patches, and other fire department (FD) memorabilia.  Before he passed, he gave us instructions to sell them and some direction on what to do with the money. After a few years of not really wanting to deal with it, my family decided to make a project out of it.  My mom, sister, wife, two daughters, and I are working our way through thousands of patches, hundreds of fire trucks, and who knows how many pendants and other trinket like items, all while working full-time jobs (school for the kiddos) and from different locations.

Dad was great about logging his patches into a Microsoft Access database, but not so good about taking pictures of them, and even worse at logging his fire trucks and other items.  The objective and high-level steps for this project were quickly identified.

The Objective

  1. Help my mom liquidate my dad’s enormous fire department memorabilia collection.

The High-Level Steps

  1. Identify the technologies to be used. Easy!
    1. Microsoft Dynamics 365 & Common Data Service – our foundation.
    2. Microsoft PowerApps – mobile app for inventory capture.
    3. Microsoft Flow – move data and attachments around, auto-create ads.
    4. Microsoft SharePoint – store ads, images. Keep large files out of CDS.
  2. Complete a first-cut of the data schema and migrate the patches data from the Microsoft Access database.
  3. Configure a software solution for the family to use so we can all capture data to a single database. Solution must be user friendly!
  4. Configure processes that streamline the creation of advertisements and other data processing.
  5. Start capturing data and creating ads!

The Players

Not everyone in an organization has the same skill level and this will certainly lead to some challenges.  With that in mind, let’s look at the players involved in our project.

  1. Mom – Low technical skill – Capable of using anything “Excel-like” to capture data.
  2. Sister – Low-to-Medium – Arguably more advanced than mom, works on a Mac. Enough said.
  3. Wife – Medium – Works around Excel with ease, understands what I do from a high level.
  4. Kids – Low-to-Medium – two daughters, ages 12 and 10. Both are geniuses on any touch device but have no clue how to work around Excel.
  5. Me – High – developer and technology enthusiast!

I’ve spent the better part of my career as a .Net developer working in SharePoint and Dynamics, among other things, so it was easy for me to decide on a path forward.  Let’s get rolling!

Configure Data Schema and Migrate Microsoft Access Data

Just so no one thinks I’m lying here for the sake of this blog, let’s see what my dad was working with back in the day.  Yes, he was ND alum.

Screenshot of patch entry form in Microsoft AccessPatch data in Microsoft Access

Side note: You see that column named “Patch Locator” highlighted in that last screen shot?  My dad kept his patches in old-school photo albums that he then stored in boxes.  This ‘locator’ field was his way of finding the patch once a box was full and stored away.  Genius dad!

As you can see defining the schema for patches was pretty much done.  If we run into anything along the way, we can certainly add it.

  1. In Dynamics I created an un-managed solution named “Fire Department Items Solution” and added two custom entities, “Patch” and “Fire Truck.”
  2. I added all the fields my dad had in his Access database, and then I made sure that the out of box field “EntityImage” was available for displaying an image of the patch.

PRO TIP:  Dynamics 365 only allows you to have one image field on an entity and it is not configured out of the box.  To use this field, create a new field on your entity and use the data type “Image”.  This will automatically set the name of your field to “EntityImage” and the image you set there will be used as your entity image at the top of the entity form.

Screenshot of PowerAppsPowerApps details

  1. Before we save and publish, we need to enable Notes functionality for our entities. To do this select the entity from the left pane in the solution explorer, then make sure the “Notes (includes attachments)” checkbox is selected.

PRO TIP:  When you save an image to the EntityImage filed it loses a lot of its quality.  Because we are using this data for inventory, including creating ads, we don’t want to lose the quality of our images.  For this reason, we will use the attachments collection for our entity to capture the actual high-quality image.  We will then use Microsoft Flow to take that image and store it as the EntityImage (which will lose quality) but also store the high-quality version in a SharePoint library.

PowerApps note functionality

  1. Finally, be sure to publish your customizations.

Migrating the Data

Now it’s time to migrate the data.  Since this was such a simple schema, I opted to use the out-of-box data import functionality that Dynamics 365 provides.  With that said, however, there are a few different ways to accomplish this migration. For me it was easy to simply export the Microsoft Access database to Excel, then use that file to import into Dynamics 365.

    1. Export your data into an Excel file from Microsoft Access.
      1. Export your data into an Excel file from Microsoft Access.
    2. In Excel you’ll want to Save a Copy and save it as a CSV file.
      Save a copy as a CSV file
    3. Open the Patch View in Dynamics and use the out-of-box Import from Excel functionality to load our data.

3. Open the Patch View in Dynamics and use the out-of-box Import from Excel functionality

    1. Choose the CSV file we just created when we saved the copy in Excel.

Choose your CSV file

    1. On this next screen, let’s click the button to Review our Field Mappings.

Review Field Mappings

    1. Here you’ll see some of my fields are mapped and some aren’t. Let’s get those shored up before we proceed.

Resolve mapped items

    1. Now that I’ve resolved all the field mappings, you’ll see we have green check marks across the board and we’re ready to import. Click the Finish Import button and you’re off.

Finish Import button

    1. You can check out the progress of the import by navigating to Settings à Data Management à

View Import progress

Summary & Next Steps

Let’s look at what we’ve done here.  On the surface it would appear we’ve simply gone into Dynamics 365 and configured a couple of entities.  But as we know, Dynamics 365 v9 was built on the Common Data Service (CDS) and that means our Dynamics data is now available to any other application that can connect to the CDS.  Why is this important for this project you might ask?  That answer will become clear in the next part of this blog.  For now, here are some screen shots on how things look now that we have our patch data migrated.

A look at the imported data

Keep in mind, come end of January 2019 everyone will need to switch over to Microsoft’s Unified Interface and that’s what we’re using here for our patches.  This is an example of a model-driven PowerApp which we’ll discuss in our next entry to this blog.

If you log in to your PowerApps environment using the same credentials as your Dynamics 365 environment, you should see your entities and the data migrated in this environment too.  Remember, once it’s in Dynamics, it’s available through the CDS.

A view of the migrated data

One thing to note, if you have 10,000-plus records like I do for patches, CDS in the browser may freeze trying to display them all.  I would hope MS resolves this at some point so that it handles paging and displaying of data as gracefully as the D365 web client does.

Stay tuned for my next entry where we’ll set up our SharePoint Online site, create a simple canvas PowerApp for inventory management on our mobile devices, and then set up a Flow to help move some things around and automate the creation of our online advertisements.

Thanks for reading!