It is a computer file known as an image that functions much like a real computer. Windows, Linux, and other operating systems can all run it.

This article presents the features and advantages of Microsoft Azure Service Fabric, a platform that simplifies the creation and administration of microservices.

This article is about automating processes, workflows, etc., using Platform as a Service (PaaS) from Microsoft Azure's Azure Logic Apps.

Azure Key Vault is a Key Management system that can be used. The encryption keys to encrypt your data are simple to create and manage.

Azure AD is a cloud service for managing identities and access that facilitates access to additional SaaS applications, the Azure portal, and external resources.

Everybody's trying to get in on the big-money future of IoT, and now "everybody" includes Microsoft with Windows 10. Larry Dignan at ZDNet put together a look at Windows 10's role in IoT - as it's been described by Microsoft CEO Satya Nadella at the Gartner Symposium ITXpo, at least - which suggests that the new OS will be a central platform for IoT systems of all types. Specifically: Windows will be able to run on everything from sensors to wearables to whatever computing shift emerges. Or, as Patrick Thibodeau at ComputerWorld interpreted it: [Nadella] sees the company's upcoming operating system Windows 10 as integral in managing every aspect of the IoT, from the sensors, mechanical systems, to the applications and analytics that underlie it. Those are some pretty big promises, but as Nadella said, Windows 10 is "the first step in a new generation of Windows as opposed to just another release after Windows 8." After all, that would be Windows 9, right? Check out Dignan and Thibodeau's coverage of Nadella at the Gartner Symposium ITXpo for more details on Windows 10 in general. It looks like a promising future: Yo Ebola, I'ma let you finish but #Windows10 is gonna have the greatest virus of all time #WindowsTillIDie — Bill Gates (@BillKingGates) October 6, 2014

This microservice building tutorial continues by walking through Eureka service discovery, the config server and user service, and configuring the email service.

Learn about Tarantool, one of the most microservice-ready, in-memory databases on the market — and it's open source!

In the era of containers (the ''Docker Age'') Java is still on top, but which is better? Spring Boot or Quarkus?

Mixing a few JBoss tools, Apache Camel, OpenShift Enterprise, and a little secret sauce to make your home smarter.

The ultimate purpose of this article is to make people break out of the bubble surrounding microservices' adoption— but to expose their shortcomings.

In this article, a developer looks at how microservices architectures are different from Service Oriented Architectures (SOA).

We continue our introductory series on microservices by taking a look at some of the advantages they offer devs and architects.

Building good microservices is tricky business. In this post, we cover some of the challenges in the process and some of the basic ways to conquer them.

Microservies and Docker have become the peanut butter and jelly of modern app delivery. They allow organizations to work in a consistent, isolated runtime environment.

With microservices' benefits becoming more important to businesses, be sure you're also familiar with the challenges they present.

How to deploy a Micronaut application using GET, PUT, and POST, and how its performance compares to when it's deployed with JVM runtime vs. as a native language.

This blog post discusses memoization - a technique that allows cost-based optimizers to consider billions of alternative plans.

I hope everyone wants a slice of Raspberry Pi because there's a lot of it this month! Here's some inspiration for your next IoT project.

This third post in this series of blogs about MaxScale is finally getting where you want to go: Install and configure MaxScale. The first blog in this series was an overview of what MaxScale is and the second about how to set up a Cluster of MariaDB servers, using MariaDB Replication, for MaxScale to access. But now it's time to introduce MaxScale. If you skipped the second post as you already know how to set up MariaDB with Replication and all that, be remineded that I will use the same Linux server setup as outlined there even for the MaxScale server and for a client to do some testing, and I recommend you stick with that for now (for MariaDB itself you can use any relevant setup you want, MaxSCale doesn't really care, but MaxScale is pretty new and has still not been tested on that many platforms, so try to stick to the CentOS 6.5 setup I propose. Installing MaxScale Start by setting up a CentOS 6.5 server as outlined in the previous blog in this series and then log in a root. Set up the server to run on IPADDR 192.168.0.165. When logged in as root, create an installation directory for MaxScale, download it and install it: # cd /usr/local # mkdir skysql # cd skysql # curl https://downloads.skysql.com/files/SkySQL/MaxScale/maxscale.preview.0.4.tar.gz > maxscale.preview.0.4.tar.gz # tar xvfz maxscale.preview.0.4.tar.gz # cd maxscale Now we have MaxScale downloaded, but for maxscale to work, the MAXSCALE_HOME environment variable has to be set up, and to achieve this we, let's create a shell-script that starts MaxScale for us. # vi maxstart.sh Then set up this script like this: #!/bin/bash # export MAXSCALE_HOME=/usr/local/skysql/maxscale/MaxScale $MAXSCALE_HOME/../bin/maxscale Once we have that script, let's make it executable: # chmod +x maxstart.sh Configuring MaxScale The next step then is to configure MaxScale. The default configuration file for MaxScale is called MaxScale.cnf and is located in the etc directory under where MAXSCALE_HOME is located. In this case we will edit: # vi /usr/local/skysql/maxscale/MaxScale/etc/MaxScale.cnf In this file, each module has it's own section, as well as each server and there is also a section for MaxScale itself. Let's begin with MaxScale which has just one variables that controls the # of threads MaxScale uses: [maxscale] threads=1 Following this, we set up the servers we are to manage here, of which there are three. For every configuration section, except the one for MaxScale core, we have to tell what type of entity we are defining here, in this case it is server: [srv1] type=server address=192.168.0.160 port=3306 protocol=MySQLBackend [srv2] type=server address=192.168.0.162 port=3306 protocol=MySQLBackend [srv3] type=server address=192.168.0.163 port=3306 protocol=MySQLBackend As you can see, we define the ip address of the server and the port that MariaDB runs on. In addition we define which protocol module to use, and in this case there is not much else than MySQLBackend to choose from. As you can see, we do not define the master or slave properties of the servers, instead we let MaxScale figure that out for us by using a Monitor module, so now is the time to define that. For the monitor to work, it will connect to the respective MySQL servers so we need to define a username and password for this. In the previous post I created a user for this called maxuser using the password maxpwd. Also, to simplify matters I created this user with full privileges, and this really isn't recommended practice for production use. Last, with MaxScale you have the option to obfuscate the passwords used in the configuration file for added security, but I am not using that feature here as I want to keep things simple. So, this is how we define this monitor: [MySQL Monitor] type=monitor module=mysqlmon servers=srv1,srv2,srv3 user=maxuser passwd=maxpwd This should be pretty straightforward, right? The module variable is a reference to the monitoring module that we are to use. With this in place, we now needs to set up the actual router, and there are two sections for this, one for the listener and one for the router. The router we are about to use is the read-write split router, which manages routing writes to the master and reads to the slaves. Let's start with the router that is the central point here: [RWSplitRouter] type=service router=readwritesplit servers=srv1,srv2,srv3 user=maxuser passwd=maxpwd The reason we need to have a username and password even for the router is that this needs to authenticate users connecting to MaxScale itself, and to do that it needs to connect to the server it manages, connect to the mysql database and get the user authorization data from there, which is why we need an account that can access the mysql database. Now we are close to getting started with MaxScale, what is left is to set up a listener for the router we defined above: [RWSplitListener] type=listener service=RWSplitRouter protocol=MySQLClient port=3306 That concludes the configuration of MaxScale! Testing MaxScale # ./maxstart.sh Now we should be able to connect to MaxScale and test that it works. We do this by setting up a MariaDB Client server. This is set up just like our previous servers, only that we only install the MariaDB client. So set up a server like before, set IPADDR to 192.168.0.167 and run, as root: # yum install MariaDB-client Now we are real close! The rest of this post assumes that you are connected to the MariaDB Client on 192.168.0.167 I here assume that you have created the t1 table that we used to test replication in the previous post, if not, create it and populate it now: # mysql -h 192.168.0.165 -u maxuser -pmaxpwd test -e "create table t1(c1 int)" # mysql -h 192.168.0.165 -u maxuser -pmaxpwd test -e "insert into t1 values(1)" Now we have a table to test with, so let's see what happens, and let's check that our SELECTs are being routed to our two slaves. We can do that by using the @@server_id variable, which is different one these two of course: # mysql -h 192.168.0.165 -u maxuser -pmaxpwd test -e "select c1, @@server_id from t1" +------+-------------+ | c1 | @@server_id | +------+-------------+ | 1 | 12 | +------+-------------+ Cool, this ended up with one of the slaves, so if I try it again, it shoudl end up with the other slave, right: # mysql -h 192.168.0.165 -u maxuser -pmaxpwd test -e "select c1, @@server_id from t1" +------+-------------+ | c1 | @@server_id | +------+-------------+ | 1 | 11 | +------+-------------+ Whoa!, it actually seems to work! Also, not that if you executed the create table above, then this got routed to the master! We are all set, right? Well, no, there are a few things left to do. And if you didn't get the MaxScale to work, like seeing this in the error log: /usr/local/skysql/maxscale/MaxScale/log/skygw_err1.log: Couldn't find suitable Slave from 3 candidates. Or if you can't connect to MaxScale, then the most likely issue is that you didn't stop iptables: # /etc/init.d/iptables stop But hopefully things work now, but that it works doesn't mean we are finished, there are some things with this configuration that needs fixing, both on the servers and in MaxScale itself, and there is also one thing to watch for in the replication setup. So the next post in the series will be about fine-tuning the MaxScale installation and the MariaDB Cluster it is accessing. /Karlsson