Azure Custom Vision AI : From training to deploying the container export on the Azure Kuberenetes Service (AKS)

Introduction

Todays post will be the backend tour of “Frietjes-of-Niet” (translated from Dutch : “French-Frites-or-Not?”). A big part of the mission of Azure is about democratizing technology so it becomes accessible to organizations in order for them to achieve more. AI (Artificial Intelligence) is a key part of that vision.

 

End-to-End Flow

What will be the flow for today?

• We’ll train a model to recognize fries
• Next we’ll be exporting that model to be used as a container
• Afterwards we’ll build that container
• To end with deploying (and testing) it onto AKS

Sound cool? Let’s get to it..

Azure : IT Governance in the cloud

Introduction

During the weekend I saw the following tweet passing by …

Hosting company Verelox has had all their customers dedicated and virtual servers wiped. Their statement: pic.twitter.com/XvAQcofJKu

— Kevin Beaumont (@GossiTheDog) June 10, 2017

Apparently, a hosting company (allegedly) got all their data wiped by an ex-admin. Now I can imagine people thinking that this is something that is part of the territory when it boils down to cloud. So I wanted to write a blog post entailing what you do to set up a governance structure in Azure. Here I’m aware that the above tweet is more related to the security aspect of governance, it’s a part of it nevertheless.

 

Governance?!?

Let’s get started on our scope… IT Governance can cover a lot of ground. In essence, the goal is to assure that the investment in IT generates business value and the risks that are associated with IT projects are mitigated. Though I found that CIO.com has a nice definition on it ;

Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance. It makes sure that all stakeholders’ interests are taken into account and that processes provide measurable results. An IT governance framework should answer some key questions, such as how the IT department is functioning overall, what key metrics management needs and what return IT is giving back to the business from the investment it’s making.

So let’s take a look at how we can put an enterprise-grade structure around the management of Azure!

 

TL;DR = Azure Enterprise Scaffold

For those who want to skip the post below… When talking about governance in Azure, the best place that summarizes it the following page in our documentation ; “The Azure Enterprise Scaffold“.

A roadmap to the cloud… Where should I focus on?

Cloud is here to stay!
A lot of questions about “THE Cloud” have risen the last years. In the beginning, the most responses included that it was a hype or that it was a rebranded solution from the past (“ASP“). Though at this point in time, it is safe to say that “Cloud Services” are here to stay and that there is no point back but to embrace them as an IT department. My personal sentiment is that the current market leaders “Amazon” & “Microsoft” will continue to grow and eventually dominate this market. As google has enough cashflow, I suspect that they will join in this battle. So the current conundrum is ; how to move your current landscape from an “on premise” way of working towards the cloud…?

Cloud Maturity Model
For organisations who are stuck with this question, I would like to point out to a fine document (“Cloud Maturity Model“) of the Open Data Center Alliance. It describes the different stages, even from different perspectives, that you will traverse in your journey.

Quote about the cloud maturity model ;

Progression through the various maturity levels is based on the evolution of a number of parallel capabilities, as described in the following figures.
The result is represented by an inferred resulting maturity, roughly mapped as follows:

• CMM 1. (Initial / Ad Hoc) The existing environment is analyzed and documented for initial cloud potential. Pockets of virtualized systems exist, for limited
  systems, without automation tooling, operated under the traditional IT and procurement processes. Most of the landscape still runs on physical
  infrastructure. The focus is on the private cloud, although the public cloud is used for niche applications.
• CMM 2. (Repeatable / Opportunistic) IT and procurement processes and controls are updated specifically to deal with cloud and who may order services and service
  elements and how. Private cloud is fully embraced with physical-to-virtual movement of apps and the emergence of cloud-aware apps.
• CMM 3. (Defined / Systematic) Tooling is introduced and updated to facilitate the ordering, control, and management of cloud services. Risk and governance controls
  are integrated into this control layer, ensuring adherence to corporate and country requirements. Complementary service management
  interfaces are operational. More sophisticated use of SaaS is evident, and private PaaS emerges.
• CMM 4. (Measured / Measurable) Online controls exist to manage federated system landscapes, distributed data and data movement, federated and distributed
  application transactions, and the cross-boundary transitions and interactions. Defined partners and integration exist, enabling dynamic
  movement of systems and data, with supporting tool layer integration (for example, service desk, alerting, commercial systems, governances).
  Cloud-aware apps are the norm and PaaS is pervasive. Hybrid apps develop across cloud delivery models.
• CMM 5. (Optimized) All service and application deployments are automated, with orchestration systems automatically locating data and applications in the
  appropriate cloud location and migrating them according to business requirements, transparently (for example, to take advantage of carbon
  targets, cost opportunities, quality, or functionality).

So far, so good… yeah? I know, this all still sounds a bit “fluffy“. The basics to remember is that there are various stages involved so you can keep track of where you are. Though for me there are three focus points that every organisation should embrace in order to be ready for the future with cloud services.

• IAAS has become commodity
• Federation is the new black
• Interoperability is mandatory

IAAS has become commodity
I do NOT believe in on-premise virtualisation farms anymore… for the majority of organisations. I must concur that there are use cases that would still require this, though for the majority of organization this is not the case. I can see you pondering “But we are special!”, and I must disappoint you, most organisations are not. Internal IT should focus on the things that deliver real value to an organisation. An Infrastructure-as-a-Service layer has become a basic commodity in the market and you should embrace it. The time you spend in maintaining the lowest layers is better invested in real business value. I, yet again, concur that this will imply a shift of skills needed…

“When the winds of change blow, some people build walls and others build windmills.” -Chinese Proverb

Federation is the new black
Let’s start with a quote from the maturity model ;

Federation refers to the ability of identity and access management software to be able to securely share user identities and
profiles. This ability allows users within a specific organization to utilize resources located in multiple clouds without having to generate
separate credentials in each cloud individually. IT is able to manage one set of identities, authorizations, and set of security review processes.
From the user perspective, this enables seamless integration with systems and applications.

For most organisations, start with setting up a federation service… Active Directory Federations Services, or a SAML provider, pick something that best fits your current technology stack. Though be aware that federation is a key, if not THE key, component of a succesful cloud roadmap!

Interoperability is mandatory
And, yet again, let’s start with a quote ;

There are two key concepts of interoperability: (1) The ability to connect two systems that are concurrently running in cloud
environments, and (2) the ability to easily port a system from one cloud to another. Both involve the use of standard mechanisms for service
orchestration and management, enabling elastic operation and flexibility for dynamic business models, while minimizing vendor lock-in.

Your high level architecture should consist of “islands”, which are linked together via APIs and/or abstraction layers and where authentication is done via federation mechanisms.

In addition, keep in mind that you will move systems around. So interoperability towards migrating systems is a key requirement and should always be a focal point in your decision-making. For instance; Think about exit scenarios with a specific cloud provider. How will you handle this?

Conclusion (TL;DR)

• Cloud is here to stay. In a few years, it will be the defacto standard.
• Infrastructure-as-a-Service has become commodity. In a few years, this segment will be dominated by Amazon, Microsoft & Google.
• Federation is the new black. If you haven’t set up a federation system… DO IT NOW!
• Interoperability is mandatory. Always keep in mind that systems should be portable islands which are built for data interaction.

The DTAP-Street : a phased approach to a development / deployment cycle

The acronym DTAP finds its origin in the words Development, Testing, Acceptance and Production. The DTAP-street is a commonly accepted method to have a phased approach to software development / deployment.

A typical flow works as follows :

• Development – This environment is where the software is developed. It is the first environment that is used. Changes are very frequent here, as this is the first area where creativity is forged into a product.
• Test – A developer is (hopefully) not alone. In the test environment, the complete code base is merged and forged into one single product. The first attempts at standardization and alignment towards the future production environment are made here.
• Acceptation – Once the development team feels that the product is ready, it will be deployed to acceptance. This is a look-alike of the production and used by operations as a staging environment for production releases.
• Production – The real deal… Here the product surely needs to be ready for prime-time.

Sometimes the following are also added ;

• Education / Training – Sometimes a dedicated environment is needed where people can test drive the software in a safe sand box. Due to efficiency reasons, this environment is often time shared with acceptation.
• Backup / Disaster Recovery – Disasters can happen… Therefore some disaster recovery plans may rely on a dedicated backup / disaster recovery location.
• Integration – An environment that is sometimes located between “Test” & “Acceptance” as an intermediate step to test certain partner integrations. Just as with the “eduction” environment, this environment is often time shared with acceptation.

What are the most commonly used formations?

• Live – Production – Many companies rely solely on a production environment. The risk reduction is often neglected in favor of the cost benefit of having one environment.
• Staging – Production/Test – If no real customization are done to the implemented software, then two environments may suffice.
• DTAP – Development/Test/Acceptation/Production – Once customization hit… then a full DTAP-street is needed to reduce the amount of risks involved with software development.
• DTAPB – Development/Test/Acceptation/Production/Backup – This is an enhanced DTAP-street that is capable of doing a disaster recovery. (Sidenote ; The Test/Development environment is often shared with the backup location. This provides the advantage that the resources of the Test/Development can be sacrificed during a disaster.)

What Code / Data flows occur between the environments?

• Software Versions – Software releases go from Development to Test to Acceptation to Production… The timing varies from the chose release management cycle, though typical times are as follows ; Development (Continuous Builds), Test (Daily Build), Acceptation (Once per quarter, three weeks before production), Production (Once per quarter)
• Data – Data flows in the opposite direction as software versions. Data is taken from production and copied to Acceptance / Test / Development. Depending on the environment (and relative security compliancy), the data may be anonymized or even reduced to have a representative production workload of a limited size.

MBTI, Insights, Belbin, … Now how do they compare?

As I’m interested in psychology, I’ve always wondered how all these known frameworks within the business context relate to eachother. Apparently Richard Sivers already investigated the same question less than a year ago ; http://www.rsaltd.com/relationships-between-mbti-disc-and-insights/

His findings are summarized in the following image ;

(Click to enlarge)

If you are looking for a more nuanced look towards your Insights profile, check the website of “Rob Purfield”, as it summarizes the types very well!

IT Budget : Run, Grow & Transform

One method of coping with your IT budget is by working with the “Run, Grow & Transform – Your business”-model. In essence is sets you to categorize your budget into three areas.

Run covers the general day to day expenses of keeping the IT infrastructure running. Actually, this is your “SIB” (“Stay In Business”). Think in terms of lifecycle management and the human resource costs to maintain your environment.

Grow covers the expenses for expansion of services or growth of the company. Things like extending your virtualization or storage farm probably fall under this category. This budget aims to help the organization introduce new capabilities or improve existing ones.

And Transform covers the costs are made to change your nature. Here you should think of things like implementing a shopfloor system when coming from a paper workflow within an industry. These initiatives might seek to identify, for example, the right technologies for new organizational capabilities; fundamental changes to business processes; or a new product or service offering.

When managing a budget in this manner, you should be able to gather tour full “Run” budget and a part of the “Grow” budget. If you fail to do so, then you have lost the confidence of your board. This part of the budget is in reality the minimal level you need to stay on par. A lower level will force you to start phasing out services from your service catalog!

Organizations that have to trim IT budgets should avoid cutting Run initiatives. Such cuts would introduce operational risk. If an organization already is going through a tough stretch, the last thing it needs is a server, application or network failure. This really is your “Stay in Business” IT budget.

Grow budget items should tie directly to the organization’s strategic initiatives. These initiatives usually are not as mission critical as Run initiatives and often have some time flexibility, which means that they are good candidates for starting early when additional cash is available, or for deferral if cash is tight.

When finances are tight, transform initiatives often are the first to be cut or deferred—unless they are associated with key strategic initiatives that the organization views as essential to its continued operation. Even if the organization doesn’t deem certain Transform initiatives immediately essential, care should be taken when considering cutting or deferring them. That’s because Transform initiatives often are key to the organization’s long-term health. Failure to provide adequate resources to Transform initiatives can stunt an organization’s future success.

Software Development Methods

Introduction
Lately I’ve been noticing that it’s not that common to understand the different software development methodologies that are being used in the field. So this post is to provide you with a quick overview.

“A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system.” Source : Wikipedia

Waterfall (Traditional)
The waterfall development model originates in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through all the phases.

More info : http://en.wikipedia.org/wiki/Waterfall_model

RUP (Iterative)
The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.

More info : http://en.wikipedia.org/wiki/Rational_Unified_Process

RAD (Spiral)
Rapid application development (R.A.D) is a software development methodology that uses minimal planning in favor of rapid prototyping. The “planning” of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

More info : http://en.wikipedia.org/wiki/Rapid_application_development

XP (Agile)
Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

More info : http://en.wikipedia.org/wiki/Extreme_Programming

SCRUM
Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control management. Its approach to planning and managing projects is by bringing decision-making authority to the level of operation properties and certainties.

More info : http://en.wikipedia.org/wiki/Scrum_%28development%29
(Another method named “Kanban” is oftenly associated with SCRUM, yet there are subtle differences!)

Closing Thoughts
Be aware that there is NO silver bullet… Each method has its own advantages and disadvantages. Be sure to study each one before choosing the right on for YOUR team. It’s not because SCRUM worked with a given team for project Z, that it will for another team that’ll code project Y. (Be aware of cargo cult!)

“Q-tools” : generate, sort, classify and perform operations on information

Check out “Dave Gray’s Q-Tools”! It’s a very interesting way to “play” with information.

Some excerpt images …

The business sweeper

The concept of a soccer sweeper is something that can be applied to business formations too. The objective of a sweeper is to clear dangers that got past the initial defense.

I know it might sound strange to see “customer request” of “business actions” as an attack, but bare with me… We tend to set up our organization in a way that we structure all the flows. Yet we often see that informal streams exist or that bottleneck situations occur. It is in these situations that a sweeper role becomes interesting.

A sweeper is mostly a player who has great insight (experience) into the play and keeps a general overview. When something happens that’s not part of our flow, then he jumps in and clears the issue. We sometimes bring in the concept of “Service Level Managers” to tackle these issues. In other coorporations they’re called a different more sexy name. The point is that you have to consider a “sweeper” role…

Who to pick?
To be honest, I haven’t finalized my view on that matter yet. Currently I see two types of persons who might fulfil the role.

• One is a young (at heart) person who doesn’t rank high in the organization. It’s a typical “hands on” guy who likes to keep a general overview of everything and isn’t shy of new things. The tough part is for his manager to get an insight on his work(load).
• The other person is kind of a “teamleader”, who manages the team (in a structural way), where he jumps in (on technical matters) when things get rough. The advantage here is that this leader knows the painful spots of the organisation, and he’s in a situation to lobby/act for corrections. An additional surplus is that he gains in respect from his peers, as he’s doing the same “shit” as they are. He’s not “boss-ing” them around.

Sidenote

• The same concept applies to Volleyball too. They have a sweeper (called libero) too. This person is in charge of doing solely defense stuff, and is not allowed in offense. He’s there to get the team out of the tough attacks and jump into the holes of the defense.
• Never use more than ONE libero (free role). It might seem tempting, but a team with more free players will forget it’s tactics and create too many holes. One should drill (procedures!) a team to create SOP’s (standard operating procedures). This organisation has to be able to catch 95%. The libero is only there when a play goes wrong!

Going 70 20 10…

The 70/20/10 Model is a business resource management model pioneered by Eric E. Schmidt. This model dictates that, to cultivate innovation, employees of a company should utilize their time in the following ratio:

• 70% of time should be dedicated to core business tasks.
• 20% of time should be dedicated to projects related to the core business.
• 10% of time should be dedicated to projects unrelated to the core business.

Source

Sound interesting? Check the following article.