In de afgelopen jaren heb ik bij verschillende opdrachtgevers in diverse branches mogen werken, zo ook bijvoorbeeld voor de overheid. Vanuit een van deze opdrachtgevers was de wens om een nieuw platform te bouwen en beschikbaar te stellen aan meerdere doelgroepen en moest deze diverse functionaliteiten ondersteunen. De keuze stond vooraf al vast dat deze applicaties en API’s via een microservices architectuur ontwikkeld zouden gaan worden. 

Kort gezegd bestaat een landschap van microservices uit applicaties die ontwikkeld zijn als een verzameling van applicaties (dus functionaliteiten). Elke applicatie kan je zelfstandig ontwikkelen, implementeren en onderhouden zonder afhankelijkheden van andere applicaties.

Om een idee te geven hoe het platform is ontwikkeld doe ik in deze net alsof wij een pizzeria genaamd “De CINQeria” zijn met soortgelijke vraagstukken, namelijk:

De consument wil een lijst van pizza’s zien, samenstellen en bestellen via de website en een app;

De pizzeria wil de bestellingen ontvangen, bereiden en bezorgen via een webapplicatie en app. 

Op basis van deze wensen kom je tot een landschap van vier applicaties (de blauwe blokken) met overeenkomende functionaliteiten (de grijze blokken), zie de afbeelding:

Naast de applicaties zullen er ook vier backend services nodig zijn, zie de afbeelding:

Pizza Service, heeft als doel om bestelbare pizza’s terug te geven;

Topping Service, heeft als doel om de toppings voor een specifieke pizza terug te geven;

Payment Service, heeft als doel om de afhandeling van de betaling te regelen;

Order Service, heeft als doel om bestellingen binnen te krijgen en te verwerken.

Sommige functionaliteiten maken gebruik van meerdere services, maar er is vanuit de functionaliteit gezien altijd maar één ingang/startpunt. Voor de functionaliteit “overzicht” zal enkel de “pizza service” benaderd worden, eveneens voor de functionaliteit “samenstellen” welke de “topping service” gebruikt. Bij de functionaliteit “bestellen” wordt het al een stuk interessanter. Om de pizza’s te kunnen bestellen zal dit via de “order service” verlopen. Omdat je natuurlijk eerst moet betalen, zal er vanuit de “order service” een beroep gedaan worden op de “payment service” zodat de betaling gedaan en geverifieerd kan worden. De functionaliteit “bestelstatus” zal via de “order service” verlopen.

Voor de consumenten zijn de ingangen naar de services voornamelijk via de “pizza service” en “topping service” om vervolgens te bestellen via de “order service”. Vanuit de CINQeria is de ingang voornamelijk de “order service”. Deze laat ons namelijk weten welke orders er zijn geweest. In een order staat onder andere informatie welke pizza’s er zijn samengesteld en of de betaling succesvol is gedaan. Om de functionaliteit “orders” en “bereiden” te kunnen doen zal de “order service” als startpunt worden genomen. Deze haalt vervolgens weer informatie op uit de andere services. Voor de consument als de CINQeria ziet het er dan ongeveer zo uit:

De communicatie van en naar services kan je op allerlei manieren optuigen. De belangrijkste regel die je moet onthouden is dat elke service zijn eigen doel heeft. De “order service” heeft (data)-afhankelijkheden van alle andere services, maar het doel is nog steeds het geven van informatie over de order. Je kunt het zien dat elke service een contract heeft voor input en output. Dat wil zeggen dat de inhoudelijke informatie van de order wordt opgehaald uit de andere services. In de “order service” staat informatie over welke pizza ID’s en bijhorende topping ID’s. Idem van de betalingstatus. Door middel van contractbeheer (schema’s definiëren, contracttesting, etc) hou je grip op wat erin en uitgaat. De data kan je bijvoorbeeld laten lopen via message queuing en het ophalen van data via GraphQL. Ook wil ik gelijk benadrukken dat alleen dit al een vak apart is tussen services.

Naast de services weten wij ook dat De CINQeria meerdere applicaties gaat gebruiken. Zo heeft elke applicatie zijn eigen gebruikers, zijn eigen doel en eigen platform. Door hier zo slim mogelijk over na te denken kom je tot een wens om een aantal dingen vast te leggen, dit zijn een Design System en Styleguide, gedeelde componenten en gedeelde functionaliteiten. Omdat allemaal te bereiken maak ik een keuze die wel toekomst vast is, maar waarin je nog wel de mogelijkheid om keuzes te maken.

Voor de CINQeria wil ik zo min mogelijk ontwikkelen en een zo groot mogelijk bereik hebben via verschillende platforms. Daarom kies ik voor een Design System uit Webcomponents (gemaakt via StencilJS) en een gedeelde library waarin ik dezelfde (deel)-functionaliteiten heb. Dan kan je ongeveer op zoiets uit:

De gedeelde library wil ik ontwikkelen met Angular, zodat de meeste applicaties hier slim gebruik van kunnen maken. De mobiele applicaties wil ik bijvoorbeeld ontwikkelen met Ionic in combinatie met Angular. Op deze manier heb ik samenwerking tussen het Design System, de gedeelde library en de applicatie zelf.

De blauwe blokken zijn nog steeds de applicaties en de oranje blokken beschrijven op welke manier. Binnen deze applicaties wordt gebruik gemaakt van de donkergrijze blokken, wat dus gedeelde functionaliteiten zijn die op hun beurt weer gebruik maken van het Design System. De lichtgrijze blokken zijn ook functionaliteiten, maar binnen de applicatie zelf. Ook deze componenten maken weer gebruik van het Design System. 

Door middel van dit artikel hoop ik jullie een klein beetje meegenomen te hebben in de wereld van microservices in combinatie met Micro Frontends. Zogezegd, zo gedaan. Ten tijde van dit artikel wist ik natuurlijk op voorhand al ongeveer wat ik wilde gaan schrijven. Toch heb ik hier en daar wat moeten aanpassen in de blokjes van functionaliteiten en services om het verhaal beter over te brengen. De belangrijkste conclusie die ik kan meegeven is keep it simple en hou vast aan het doel van de service of applicatie. Hoort dat echt bij die service of wordt het op nog meer plekken gebruikt? Is het daarom reden voor een eigen service? Maar let op; blijf bij de les. Het landschap aan services groeit snel, dus zorg altijd dat je het onder controle hebt met contractbeheer en testing. Een gewaarschuwd mens telt voor twee.

Een landschap van microservices uit applicaties (van frontends) die ontwikkeld zijn als een verzameling van applicaties (dus functionaliteiten).

De CINQeria; een wereld van microservices en frontends

Until recently, the Cloud Native Compute Foundation (CNCF) only provided certifications for very experienced hands-on Kubernetes skills, i.e. CKAD, CKA and CKS. In this article I will give you a quick overview of CNCF's latest addition: KCNA.

The existing credentials CKAD, CKA and CKS are well-known and respected in the Kubernetes community, but there were still two gaps:

There were no Kubernetes beginner certifications.

There were no certifications about any of the other 100 CNCF projects.

Therefore, CNCF created a new credential called Kubernetes and Cloud Native Associate (KCNA) which has been available since November 18th 2021 and aims for

I've already proven my Kubernetes skills by getting CKAD, so my interest was more in the part about the cloud native ecosystem. I consider it as a gap in my own knowledge. I know some tools very well, some little, but most of them not. Well, that probably holds for anybody since there are just so many CNCF projects:

Kubernetes is by far the biggest project, but some others have earned their place as well, like Prometheus, Helm, and Linkerd - as you can see in the image below.

Graduated project velocity, from the CNCF annual report 2021

By becoming a Kubernetes Certified Service Provider CINQ ICT earned some CNCF vouchers, so I used one to see what the Kubernetes and Cloud Native Essentials course and KCNA exam learns me about the rest of the cloud native ecosystem.

Kubernetes and Cloud Native Essentials - course

As expected, I was scanning and skipping most of the Kubernetes chapters. However, the content was well written, holistic and complete and provide a very good fundamental for Kubernetes beginners. Personally, I especially enjoyed the "additional resources" paragraphs, which contains links to some very good blogs and docs about all kind of Kubernetes fundamentals e.g. Docker v1.0 announcement, fundamentals of container networking, difference between OCI v.s. CRI and Docker v.s. Containerd, difference between containers and pods. Most of them go way deeper into Kubernetes than needed for the KCNA exam, but where therefor very interesting to me.

Putting my hopes on the final two chapters on Cloud Native Application Delivery and Observability, my hopes vanished quickly when I started reading them. The cloud native ecosystem is only touched lightly, with just a little extra attention to Prometheus basics. Other than that, it's more like an overview on which tool does what with minimal descriptions.

During the exam almost no questions about the rest of the cloud native ecosystem came by. Which makes KCNA even more just a beginners Kubernetes credential. 

All together it's nice that there is an entry-level Kubernetes certification now, it was definitely missing. For engineers that are starting their journey in the world of Kubernetes, this is definitely a great way to start. The part about cloud native ecosystem is disappointing. Also from a beginners point of view. So for CNCF, there is still a gap left and I hope it will be filled with some sort of certification on the cloud native ecosystem in the future. 

https://docs.linuxfoundation.org/tc-docs/certification/important-instructions-kcna

https://www.cncf.io/announcements/2021/11/18/kubernetes-and-cloud-native-essentials-training-and-kcna-certification-now-available/

https://training.linuxfoundation.org/training/kubernetes-and-cloud-native-essentials-lfs250/

https://www.cncf.io/cncf-annual-report-2021/

https://www.cncf.io/announcements/2021/02/24/cloud-native-computing-foundation-welcomes-47-new-members-at-the-start-of-2021/

Until recently, the Cloud Native Compute Foundation (CNCF) only provided certifications for very experienced hands-on Kubernetes skills, i.e. CKAD, CKA and CKSS. In this article I will give you a quick overview of CNCF's latest addition: KCNA.

Kubernetes and Cloud Native Associate (KCNA)

Het had dé dag had moeten zijn waarop we met alle CINQ collega’s een spetterend feest in Hotel Jakarta gingen vieren. Maar we laten ons niet zomaar uit het veld slaan, dus bedachten we: de CINQ Drive-Through! 🚘 🎁

Op vrijdagmiddag nodigden we al onze collega's uit om over de parkeerplaats bij CINQ door de drive-through te rijden. De Sint én de Kerstman stonden klaar om onze collega's, hun partners, én hun kinderen van cadeaus te voorzien. Met een beker warme chocolademelk met slagroom en een auto vol cadeaus en blije gezichten reed men de parkeerplaats af. Missie geslaagd! 🥳

🚘 AFTERMOVIE CINQ DRIVE-THROUGH 🎁

Het had dé dag had moeten zijn waarop we met alle CINQ collega’s een spetterend feest in Hotel Jakarta gingen vieren. Maar we laten ons niet zomaar uit het veld slaan, dus bedachten we: de CINQ Drive-Through!

Bekijk de aftermovie van de CINQ Drive Through

Bekijk de aftermovie van de CINQ Drive-Through

Site Reliability Engineering (SRE) is a new discipline which is quickly gaining traction within the IT landscape. First conceived by Google, it is now adopted mainly by large enterprises such as Netflix, LinkedIn, Target, Tesla and many more. It is known for a focus on automating manual tasks without enduring value (toil), treating operations as a software problem and its unique approach to systems reliability. You might hear of the advantages of SRE and want to introduce it to your organization. Perhaps you are a software engineer and want to convince your peers to try it out or you are a manager overseeing one or more teams and would like to introduce SRE to them. The question is, are you ready to start?  

In this article I would like to give you some tips and tricks in order to judge how ready your organization is for this SRE journey and if it is already adopted, determine the current level of SRE maturity.

As Google describes it, SRE is a superset of DevOps. Many of the SRE principles align with DevOps and build upon them. Having good adoption of DevOps principles is therefore an important factor in the success of implementing SRE. Is the DevOps maturity level relatively low, then you will likely benefit more by focusing on improving that first. 

Google describes a number of levels in automation, the higher levels (lower on the list) being more advanced:

No automation - all operational tasks are performed manually

Externally maintained system-specific automation - operational tasks are performed using external systems such as scripts, specific for this one system

Externally maintained generic automation - there are generic systems that can perform tasks on multiple different systems

Internally maintained system-specific automation - systems include automated operational tasks out-of-the-box

So, what makes the higher levels better than the lower levels? Why is it better for a system to be internally monitored than externally? If you use an external system to monitor another system, you are now managing two systems. This usually increases the effort to maintain this process. 

A system that is internally automated also has more possibilities to do so as it can directly tap into all of the functionality and therefore has more fine-grained control. If the automation is system specific as opposed to generic, the impact of this particular automated task is not as broad and use of these tasks scales more linear.

If you are low on this scale (less flexible and in lower amounts of automation), there will be more to be gained from automation but some aspects of SRE might not fully come into fruition just yet. SRE works best if there is a foundation of automation upon which to build. Additionally, hiring SRE engineers is easier as the profile of SRE engineers usually includes skills which are a match for more mature forms of automation. 

When it comes to SRE as a term, there are usually three definitions used. 

As a set of practices and principles - the SRE discipline

In practice, these definitions are often intertwined and mixed depending on the context of discussions.

These definitions are commonly used in a number of forms of adoption. Depending on structure of your organization and how much knowledge about SRE is present and some of its principles are perhaps already adopted.

Consulting - SRE maturity level is zero to non-existent. Consultants provide guidance and advice but do not actively participate in engineering activities.

Embedded - SRE maturity is at a low level. Consultants actively participate in engineering but also keep sharing knowledge and giving direction

Platform - For medium SRE maturity. A SRE-minded platform team takes care of all supporting services and/or infrastructure for services.  Knowledge about delivered services is limited

Slice and Dice - Again for medium SRE maturity. Services are divided into functional slices such as payment processing or the user-facing helpdesk. SRE engineers responsible for this slice have knowledge of the complete 'flow' of the service and can therefore better tailor to automation needs

Full SRE - High SRE maturity. The full scope of a particular service or set of services involves SRE engineers and all team members have an SRE mindset

For all maturity levels there are gains to be made from adopting SRE and the aforementioned forms tailor to these varying needs. The red line in these forms is that as the SRE maturity level progresses, the scope of SRE widens and more of the service delivery flow is imbued with SRE practices and principles. Choose the form that suits the maturity level to make the most out of SRE adoption. 

So, know knowing there are different forms to adopt based on the maturity level, how can you judge how high the SRE maturity level is? Assuming SRE is already implemented to some degree, there are some indicators.

There is executive buy-in on an SRE strategy. Investing in SRE means investing more in reliability than velocity if reliability is under a certain threshold. For a lot of teams it means more investment in automation than new features, in the hopes it pays itself off in the future. As executives usually have a say in high-level/abstract strategy, they have to agree to one which includes SRE for it to work.

SREs are involved early in the service design process and can exert influence. Designing a service to be reliable and observable, among other things, is easier in earlier stages of the design process than post-facto.

There is a broad focus on automating repetitive tasks. If you can distinguish many operational tasks which still require manual labor and are not on the agenda to be addressed, likely there is still room for improvement in terms of SRE adoption

Both current incidents are mitigated and future ones. Good SRE engineers practice anti-fragility: managing a service that is not only stable under normal operating conditions but also can recover easily when disaster strikes. Additionally, if monitoring is adequately implemented and operational tasks have a high degree of automation, solving incidents should be a lot easier.

The key take-away here is to inspect how well integrated SRE is in the process and how effectively they handle automation, incident response, the degree to which SREs are involved in the design process and whether there is executive buy-in. In other words, is SRE implemented well and is there is support within the organization. 

Next to the SRE maturity level as a whole, there is also a way to judge the progression in terms of handling reliability. Effectively handling reliability is a key component of any SRE strategy and how it is dealt with is a good indicator on SRE maturity.

Reactive - Incidents are responded to after they happen. There is rarely any lessons learned and investments to reduce the number of incidents is limited

Proactive - The possibility for incidents are identified before they can occur and measures are taken to prevent them from happening

Strategic - Efforts are made to include reliability as an aspect to be specifically addressed in architectures, products and processes

Visionary - Reaching beyond the scope of the organization and getting involved in the broader spectrum. For example: Writing papers, giving advice to other organizations and making videos.

The saying "it is better to prevent than to cure" also applies to reliability. So being at the very least proactive to incidents is a good move to make. However, it is not needed to be very high on the spectrum per-se. It requires major investments in order to become a visionary on reliability and the benefits might not outweigh the costs of doing so. 

The key takeaway here is that there are various ways to judge how your organization fares in terms of SRE maturity. Depending on the maturity level, there are different rates of progression and approaches to advance on this level. 

A more 'junior' organization might focus more on making automation more generic, hire consultants to help with determining SLOs and make their incident response more proactive. 

A 'senior' organization will focus on developing tooling which comes with its own automation, broaden the scope of their existing SRE teams to include more of the service delivery flow and share knowledge about SRE with other people. Regardless of the maturity level, there are gains to be had but the right approach for the right level will mean gains will be maximized.

https://cloud.google.com/blog/products/devops-sre/evaluating-where-your-team-lies-on-the-sre-spectrum

https://cloud.google.com/blog/products/devops-sre/the-five-phases-of-organizational-reliability

https://sre.google/sre-book/automation-at-google/

You might hear of the advantages of SRE and want to introduce it to your organization. Perhaps you are a software engineer and want to convince your peers to try it out or you are a manager overseeing one or more teams and would like to introduce SRE to them. The question is, are you ready to start?

Is your organization ready for SRE?

Een product als Splunk, komt vaak op een gefaseerde manier de organisatie binnen. Beginnend met wellicht een Proof of Concept met een enkele server begint men met Splunken. De waarde wordt al snel duidelijk, meer collega’s worden enthousiast en zo langzaam aan worden er steeds meer dashboards, alerts, rapportages en andere knowledge objecten gemaakt. Die ene Splunk server groeit uit naar een eerste cluster, Splunk groeit in de organisatie van 1 tot misschien wel honderden unieke gebruikers per dag. 

Dit is een realistisch scenario dat we bij veel klanten tegenkomen, in de tussentijd zijn er veel collega’s gekomen en gegaan. Daardoor is de kans dat alle knowledge objecten nog relevant zijn kleiner geworden. Uit angst om bestaande functionaliteiten te slopen, wordt er dan vaak besloten om de objecten te behouden “want je weet maar nooit…”. Maar dit kan ten koste gaan van de performance van de Splunk omgeving. 

Waarom is het zo belangrijk om je Splunk omgeving “schoon” te houden? 

Alle tags worden bij elke search geraadpleegd. Dit gaat ten koste van je search performance. Als de tags actief gebruikt worden, weegt het gebruikersgemak wellicht wel op tegen de degradatie van de search performance. Maar gebruik je tags niet meer? Dan is het uiteraard zonde om daar search performance aan kwijt te zijn. 

Wat dacht je van saved searches? Een saved search draait op de achtergrond volgens zijn cron schedule, misschien zelfs wel elke minuut! Als een SAML user verwijderd wordt uit de Active Directory, betekend dit niet automatisch dat hij ook verwijderd wordt uit Splunk. Zo kan het dus zijn dat de objecten van een ex-collega die al maanden geleden het bedrijf heeft verlaten, nog steeds impact hebben op jouw dashboards! Wil jij de performance van je Splunk omgeving verbeteren, maar is uitbreiden geen optie? Dan is het tijd voor Splunk Housekeeping, met ons nieuwe dashboard!

Bij CINQ hebben we een nieuw dashboard geïntroduceerd bij onze klanten die inzichtelijk maakt wat de relaties zijn tussen de knowledge objecten in Splunk. Tags kunnen gebruikt worden in dashboards, search macro’s en saved searches. Saved searches kunnen op hun beurt gebruikt worden in dashboards, search macro’s en zelfs in andere saved searches. Lookups kunnen gebruikt worden in dashboards, saved searches en search macro’s. Nogal wat complexe relaties dus! Standaard zijn die relaties in Splunk niet direct zichtbaar, maar met ons nieuwe dashboard wel!

Met het app overview dashboard wordt structuur gecreëerd in de chaos van knowledge objecten. De naam zegt het al, per app wordt er een mooi overzicht gemaakt van de knowledge objecten die bestaan in de app. Er wordt gecontroleerd wat de relaties zijn, of het gebruikt wordt en of het op een juiste manier gedeeld wordt met andere gebruikers. Het dashboard hoeft ook niet geconfigureerd te worden, zodat deze werkt op jouw Splunk omgeving, hij werkt out of the box!

Per knowledge object wordt in kaart gebracht of deze relaties heeft met andere objecten en zo ja, welke dan. Op die manier hoef je nooit meer bang te zijn dat je een object verwijderd die stiekem toch nog ergens gebruikt werd. Maar je hoeft ook zeker geen objecten te laten staan omdat men niet meer weet of deze nog gebruikt worden. Met behulp van dit dashboard, kun je precies zien wat je wel en niet kunt verwijderen.  Als je ongebruikte searches, lookups en andere objecten verwijderd, verbeter je de performance van de Splunk omgeving - en houd je de boel lekker schoon!

Ben jij nieuwsgierig geworden naar de mogelijkheden voor jouw Splunk omgeving? Neem dan gerust even contact met ons op, we geven graag een demo. 

Verbeter de performance van je Splunk omgeving met het CINQ housekeeping dashboard. Bekijk de mogelijkheden en neem contact op voor een demo op maat.

Verbeter de performance van je Splunk omgeving met het CINQ housekeeping dashboard

Up until Splunk 8.2 Splunk has been lacking in the visualization department, as it relied on simple XML to create its dashboards. Although dark mode was a welcome addition in Splunk 7.2, you are still bound by a grid layout and limited options to customize the dashboard. If you wanted to add an image to your dashboard as a user you had to ask your Splunk team to add the image to the Splunk app so that you as a user could use it. 

Here's a look at an example of a traditional Splunk dashboard:

Starting with Splunk 8.2 there is now a new prompt when you want to create a dashboard: 

You can now choose between Classic Dashboards (simpleXML) or Dashboard studio(JSON)

When you choose Dashboard Studio you also get to choose the layout mode Absolute or Grid.
In this example we are using Absolute to see what we can do. You get a blank canvas where you can set a background color or image. At the top left there are the buttons to add the following:

-        Visualizations 
-        Inputs 
-        Icons 
-        Shapes 
-        Images
-        Text 

To start I added a picture and a few simple singles to the dashboard. 

Then I tried to move the picture around change the background color and added a table. It is awesome to see that you can just drag and drop each element to where you want them. 

It is also pretty easy to change the background color of each element or even to make it transparent.

The one thing to realize is that Splunk no longer uses xml as the backend for the dashboard but JSON. So if you do decide to change something you will see something like the following:

For long time Splunk users, this might take a while to get used to. 
You can use this article in the Splunk docs to see what options you could add in the JSON file for your visualizations. Splunk also provides an example hub which shows visualizations and even complete dashboards as examples to get an idea of what you could do with dashboard studio.

If you already have dashboard that you made in older versions of Splunk you can open it in Splunk and select the 3 dots in the top right corner.  This will give you the option to select Clone in Dashboard Studio.

The layout might not be a 100% match but at the very least you get all of the searches and visualizations that you had on your old dashboard.  

All in all the new dashboard studio is a welcome change for Splunk users as it finally gives users more options and flexibility in how they want to present their data. For Splunk admins: if you are planning to upgrade to 8.2 make sure you inform your users and be prepared to get questions about the usage of Dashboard Studio.

In this blog, we will show you some examples of the new Dashboard Studio features in Splunk 8.2.

Create more complex dashboards with Splunk 8.2 Dashboard Studio

This blog gives you five exam tips for the Splunk Phantom Certified Admin exam. This is based on my experience following the courses and passing the exam earlier this year. I hope this will help you prepare and pass the exam yourself! 

To become a Splunk Phantom Certified Admin there are three courses that you can follow:

The courses are not required but I highly recommend you do them, they give great insights in how to use Splunk Phantom. More detailed information about the Splunk Phantom certification track can be found on the Splunk website.

During the courses you are provided with virtual instances for the practical labs. If you finished the lab you can use the remaining time to check out what Splunk Phantom has to offer. And here is the good thing: Between the training days the instances stay up so if you have an hour to spare log in and retake the steps from some of the more complex labs to make sure you are familiar with the interface.

There are several apps on Splunk Base that have Phantom in the name:

In the Advanced Phantom Implementation course most of these apps are discussed and implemented. It is good to know what each of the apps is used for. So give them a try and know what they are about for the exam. 

If you did not have the time to experiment on the instances provided during the labs, you can easily set up a virtual machine at home using the provided OVA. An OVA is an Open Virtualization Format which you can use to install a virtual instance of Phantom. 

To install it you can follow the steps provided by the documentation: https://docs.splunk.com/Documentation/Phantom/4.10.6/Install/InstallOVA

If you also want to use Splunk you could install it yourself or use the containerised version with Docker: https://docs.splunk.com/Documentation/Splunk/8.2.1/Installation/Chooseyourplatform 

4.    Know the steps to develop a playbook

In the Developing Playbooks course they share some of the best practices to develop a playbook, try and think of a real world scenario and follow the steps in the I2A2 process. This will help you with questions in the exam and will help you prepare for your first playbook. 

In the Developing Playbooks and Advanced Phantom Implementation Splunk provides Playbooks for some of the labs. Make sure you import these examples and study these, they might have used different steps than what you did during the labs. They are also handy as reference material if you need to format data before it can be used in an email for example. 

By following these courses and trying Phantom out you should have enough knowledge to pass the exam. You should also be able to create a Proof of Concept to see if Phantom is the right solution for your company. 
You should know that Splunk is currently actively working towards cloud driven solutions and that is why they announced Splunk SOAR, which essentially is Splunk Phantom in the cloud.

In this article we give you 5 tips to help you pass the Splunp Phantom Certified Admin exam.

5 Tips to pass the Splunk Phantom Certified Admin exam (2021)

5 tips to pass the Splunk Phantom Certified Admin exam

Zoveel tooling belooft inzicht te geven in data, maar klanten zien als snel door de bomen het bos niet meer. Dan bedenken we toch zelf een oplossing? Onze slimme data-oplossing geeft inzicht in de use-case van de klant voor business én IT. Iedere use-case is namelijk uniek en verschilt per afdeling of niveau. De zakelijke kant wil andere inzichten hebben dan een IT-manager of beheerder. Logisch. Doordat wij inzichten bieden op verschillende organisatieniveaus, creëren we een objectief beeld voor iedereen. En zo helpen we klanten van data naar daden. 

De kosten en baten van een hogeschool of universiteit hangen nauw samen met het aantal studenten. Elke instelling beschikt daarmee over een bepaald budget dat zij dusdanig moet inzetten zodat studenten optimaal ondersteund worden tijdens hun studie.  Maar wat kost een student nou eigenlijk? Op die vraag hebben we antwoord kunnen geven bij één van onze klanten. 

Kosten voor een student zijn o.a. accounts, docenten, softwarelicenties en  gebouwen. Om deze kosten beter inzichtelijk te maken heeft CINQ bij een hogeschool met behulp van Splunk een datastroom opgezet waarbij data uit verschillende bronnen in één overzicht gevisualiseerd zijn.

In augustus neemt het aantal studenten een vogelvlucht door alle nieuwe aanmeldingen, in februari stromen de eerste studenten weer uit en sommige verlengen de studie voor een geheel jaar. Door constante monitoring op het aantal studenten hebben we voor deze hogeschool de kosten inzichtelijk én pro-actief beheersbaar gemaakt.

Door het visualiseren en doorzoekbaar maken van deze data, wordt de informatie nu ook ingezet voor andere doeleinden. Zo heeft een IT support medewerker meteen inzicht in de gegevens van de student wanneer deze belt voor een probleem. De security afdeling weet preventief events op te lossen voordat dit voor incidenten zorgt. Het samenvoegen van meerdere databronnen tot één punt leidt tot informatie die de gehele organisatie verder helpt.

Weten wat CINQ voor jouw data kan betekenen? Neem contact op voor een vrijblijvende kennismaking. We maken graag een demo op maat.

Data klantcase: Inzicht in de kosten van een hogeschool

In een eerder blogartikel benadrukte ik dat een native app ontwikkelen lange tijd gezien werd als een must. Ik legde de nadruk op de keuzes die je kan maken om de juiste beslissing te kunnen maken. Daarin had ik mij voorgenomen om niet specifiek te richten op de mogelijkheden van native apps. Voorheen werd specifiek ontwikkelen voor Apple of Android als ‘lastig’, ‘duur’ en ‘veel tijd’ ervaren, omdat je dit moest doen in verschillende talen; namelijk Swift en Java/Kotlin. Om dit probleem op te lossen heeft Google een cross-platform gelanceerd genaamd Flutter. Is Flutter daarmee de toekomst van cross-platform native apps?

UI-toolkit voor native compiled applicaties voor mobile, web en desktop

Flutter zet zichzelf in de markt als een UI-toolkit om native compiled applicaties te ontwikkelen voor mobile, web en desktop. Dit doe je door middel van een single codebase, wat wil zeggen dat je één stuk code hebt wat zich laat compileren naar de specifieke platformen die jij wenst. Om een Flutter app te ontwikkelen zal je de (vrij) nieuwe programmeertaal Dart je eigen moeten maken. Flutter leent zich ervoor om snel te ontwikkelen door Stateful Hot Reload en ben je de baas over elke pixel van de applicatie. 

Dart lijkt enigszins op een combinatie tussen Java/C# en Javascript. Het verdeelt zichzelf over drie verschillende eigenschappen. Een geoptimaliseerde UI, productieve development ervaring en snelle performance op alle platformen. Dart is – volgens wat zij zelf schrijven – makkelijk om te leren. Je kunt gemakkelijk code (on)afhankelijk van elkaar maken. Door middel van je eigen editor kan jij dingen als debugging snel voor elkaar krijgen. Ook passen zij AOT-compile toe om zo de juiste performance ervaring te bereiken. 

Voor meerdere platformen (snel) ontwikkelen vanuit een single codebase

Ook mogelijkheid tot het compileren van een native desktopapplicatie

Voorzien van een herkenbare/vergelijkbare architectuur

Beschikbare widgets zijn getest en makkelijk te gebruiken

Dart-code het meest dicht bij het native platform

Regelmatig breaking changes, onderhoud kan een uitdaging zijn

Geen mogelijkheid tot specifieke UI voor verschillende platformen

Programmeren in Dart vereist een leer curve, maar makkelijk te leren

Niet volledige mogelijkheden kunnen benutten van de telefoon

Niet de eerste keuze voor kleine apps (compileert veel)

Als je kijkt naar de voor- en nadelen, dan zie je gelijkenissen met andere hybride frameworks. De juiste keuze hangt af van ervaring, doelen en vereisten. Flutter zou ik overwegen wanneer de focus echt ligt op performance. Het is hoe dan ook sneller dan oplossingen die door middel van een webview wordt geladen. Door de vele breaking changes zou ik eerder neigen bij grotere apps voor een andere oplossing (bijvoorbeeld React Native) te kiezen. Het heeft – net als vele anderen frameworks – zeker potentie. Nogmaals verwijzend naar mijn eerdere blogartikel, voeg daarbij Flutter zeker toe als optie.

Lost Flutter het probleem op om niet meer per platform te hoeven ontwikkelen? De mogelijkheden zijn er, maar is Flutter de toekomst?

Flutter, de toekomst van cross-platform native apps?

Is Flutter de toekomst van cross-platform native apps?

Sinds Docker Enterprise is overgenomen door Mirantis is de naamgeving van het productportfolio compleet aangepast. Docker Enterprise heet tegenwoordig Mirantis Container Runtime, Universal Controle Plane (UCP) heeft de naam Mirantis Kubernetes Engine (MKE) gekregen en Docker Trusted Registry (DTR) heet Mirantis Secure Registry (MSR). 

Voor een opdracht bij een klant waar de omgeving voor 95% bestaat uit Windows Server 2019 en .NET als ontwikkel taal wordt gebruikt, is Linux een vreemde eend. Wat de opdracht interessant maakt was dat .NET containers gingen landen op Windows Server 2019 Core.

Dit in combinatie met een nieuwe Linux omgeving, waar MCR\MKE en MSR op geïnstalleerd werd. Om dit voor elkaar te krijgen zijn we aan de slag gegaan met Ansible-playbooks. Binnen de organisatie had men kennis hiervan, dus het toepassen van infrastructuur als code was bekend.  In deze opdracht zijn verschillende Ansible-playbooks gemaakt, waaronder het hardenen van de Linux omgeving zodat voldaan werd aan het security beleid. De betreffende playbooks werden in een repository geplaatst zodat versie beheer kon worden toegepast.

Het onderstaande voorbeeld werd o.a. gebruikt voor het het opzetten van de verschillende MKE-Clusters, d.m.v. Ansible code. Door gebuikt te  maken van de playbook kun je met 1 druk op de knop een MKE single node cluster opzetten, inclusief MSR en een Linux worker Node. Hoe we dit gedaan hebben leg ik hieronder uit. 

Om met de tutorial aan de slag te gaan heb je een PC of laptop met minimaal 16GB geheugen nodig, Vagrant en VirtualBox dient geïnstalleerd te zijn.

git clone https://dennisvermeulen@bitbucket.org/dennisvermeulen/mirantis-cluster.git

cd mirantis-cluster/

mirantis-cluster % vagrant up 

Installatie MKE/MSR met behulp van Ansible

mirantis-cluster % vagrant ssh vm1

[vagrant@cinqmke ~]$ cd ansible-mke-msr-wor/

[vagrant@cinqmke ansible-mke-msr-wor]$ ansible-playbook -b -K -i vm_hosts site.yml

BECOME password: vagrant 

Nadat alles ingesteld is via Ansible krijg je de onderstaande output.

Nu kun je inloggen in Mirantis Kubernetes Engine (MKE) en Mirantis Secure Registry met username “admin” en password “welcome01”.

Kies Next en plak onderstaande code in het veld Add Application File.

version: '3.7'
services:
  nginx:
    image: nginx:latest
    ports:
      - target: 80
        published: 5000
        protocol: tcp
        mode: host

Kies Create, wacht en ga naar de volgende URL http://192.168.33.72:5000. Als het goed is zie je dan de bevestiging dat nginx draait. 

Door het bestand vars in de directory ansible-mke-msr-wor/group_vars/ aan te passen heb je grip over de verschillende versies. Zie hiervoor ook: https://docs.mirantis.com/containers/v3.1/dockeree-release-notes/index.html

Wanneer je gebruik wilt maken van een MKE multinode cluster pas je het vm_host bestand aan in de directory ansible-mke-msr-wor.

Ruim de omgeving op, ga hiervoor als volgt te werk.

[vagrant@cinqmke ansible-mke-msr-wor]$ exit
mirantis-cluster % vagrant destroy
    vm3: Are you sure you want to destroy the 'vm3' VM? [y/N] y
==> vm3: Forcing shutdown of VM...
==> vm3: Destroying VM and associated drives...
    vm2: Are you sure you want to destroy the 'vm2' VM? [y/N] y
==> vm2: Forcing shutdown of VM...
==> vm2: Destroying VM and associated drives...
    vm1: Are you sure you want to destroy the 'vm1' VM? [y/N] y
==> vm1: Forcing shutdown of VM...
==> vm1: Destroying VM and associated drives…


 Pas het bestand aan, zoals hieronder aangegeven.

 mirantis-cluster % vi ansible-mke-msr-wor/vm_hosts


### MKE
[mke_main]
cinqmke ip_addr='192.168.33.70'

[mke]
cinqmke ip_addr='192.168.33.70'
cinqmsr ip_addr='192.168.33.71'
cinqwor ip_addr='192.168.33.72'

### MSR
[msr_main]
#cinqmsr ip_addr='192.168.33.71'

[msr]
#cinqmsr ip_addr='192.168.33.71'

### WORKER
[worker]
#cinqwor ip_addr='192.168.33.72'

mirantis-cluster % vagrant up 

Opnieuw installeren m.b.v. Ansible en je krijgt een multinode cluster:

mirantis-cluster % vagrant ssh vm1
[vagrant@cinqmke ~]$ cd ansible-mke-msr-wor/
[vagrant@cinqmke ansible-mke-msr-wor]$ ansible-playbook -b -K -i vm_hosts site.yml
BECOME password: vagrant
 

Met behulp van Ansible playbooks kun je met 1 druk op de knop een volledig MKE/MSR single- of multinode cluster opstarten en dit allemaal zonder al te veel inspanning. Ik hoop dat je er met deze tutorial uit komt. Als je vragen hebt, neem gerust contact met me op via email. 

In deze tutorial ga je met behulp van Ansible een multi-node Mirantis Container Engine (voorheen Docker Enterprise) cluster opzetten.

Met Ansible een Mirantis Container Engine cluster opzetten

In mei is Splunk 8.2 gelanceerd en in deze blogpost licht ik een aantal van de nieuwe functionaliteiten toe. Vooral Federated Search en Dashboard Studio zijn de moeite waard om je een paar uur in te verdiepen. 

Eindelijk daar is 'ie dan: Federated search! Met federated search kunnen search heads (clusters) zoeken in verschillende Splunk omgevingen. Er kan bijvoorbeeld een mix gemaakt worden van on-premise en cloud Splunk instances. Voor klanten met grote omgeving waarbij meerdere cloud providers gecombineerd worden met een deel on-premise is dit een hele handige functie. Zo kan data binnen de omgeving blijven waar deze al is maar kan wel in 1 Splunk omgeving (search head) doorzocht worden. In de afbeelding hieronder is schematisch weergegeven hoe dit werkt. De search head maakt verbinding met de federated provider 1 en kan hiermee via de search head in dat cluster de data in de indexers doorzoeken. Ook is het mogelijk remote datasets te kunnen gebruiken. Die datasets zijn erg interessant want hiermee is het ook mogelijk om lokale lookup files uit te kunnen lezen in een ander cluster. Erg handig wanneer er bij 1 klant meerdere search head clusters zijn (vaak het geval wanneer de klant 1 of meerdere enterprise apps draait zoals Enterprise Security of ITSI).

Meer informatie over hoe dit technisch in elkaar steekt staat hier.

Iedereen die wel eens met Splunk werkt weet dat het dashboard maken best prima werkt zolang je een standaard dashboard maakt. Maar als je iets buiten de gebaande kaders wil dan moet je aan de gang met zelf geschreven CSS en JavaScript. Werkt redelijk maar echt top werkt het niet. Daar is Splunk zelf inmiddels ook achter en daarom hebben ze dashboard studio gelanceerd. In dashboard studio kun je met een makkelijke interface gave dashboards zoals hierbeneden maken. Top om binnenkort op een regenachtige vrijdag middag eens even mee te spelen!

Backup & restore KVstore; niet nieuw maar wel fors verbeterd.


Durable search; waarmee kan worden geforceerd dat scheduled reports/alerts opnieuw uitgevoerd worden als de results incompleet zijn.


Improved handling of JSON; de functies json_array_to_mv, mv_to_json_array, json_append function en json_extend zijn toegevoegd. 

Voor het complete overzicht van alle nieuwe features in Splunk 8.2, bekijk de  Splunk Docs.

Splunk 8.2 is nog niet productie ready (ik zou dan nog even wachten tot 8.2.1) maar voor de testomgeving is dit zeker al aan te raden!

Maak gebruik van de Python Update Readiness app om te bepalen of je omgeving klaar is voor het uitfaseren van Python 2.7.

In mei 2021 is Splunk 8.2 gelanceerd en in deze blog bespreken we twee mooie nieuwe features: Federated Search en Dashboard Studio.

Federated Search in Splunk 8.2

Federated search nu beschikbaar in Splunk 8.2

Vakmensen, dat zijn we. En wat we doen op het gebied van informatie- en communicatietechnologie helpt organisaties slim verder. Effectief en meetbaar bovendien. Aangenaam, CINQ. Specialisten in Data, DevOps en Development. Wij geloven in specialisten, vandaar de driedeling Data, DevOps en Development binnen ons bedrijf. Zo zorgen we dat jij excelleert, want je werkt het best waar je je het meest thuis voelt. Logisch, toch?

cinq_logo.png

cinq_logo_square.png

CINQ ICT

We delen graag onze kennis over Data, DevOps en Development met je. Op ons blog lees je tips en tricks over bijvoorbeeld Splunk, Docker, Kubernetes en Java.

Onze laatste blogs