Tag: computers

It is increasingly necessary to integrate applications across multiple datacentres and cloud environments.  To further complicate matters BYOD and home access need to be provided as well.  This problem transcends integration, and a solution for integration can be extended to secure web apps and mobile device management.

PaaS, SaaS and IaaS provide different secure networking solutions.   They all work well in the simple case where you have one *aaS solution connected to your secure network.  But these days people need to have multiple solutions connected with any number of interconnections.

An example I have to work with has integration provided in an AWS VPC which has a VPN connection into 2 datacentres, peering with another AWS VPC, a VPN to another SaaS provider and a VPN to another VPC in Azure.  The IP addressing ran out in the VPC and it had to be moved to another (larger) IP range.  This meant duplicating all those VPNs.  Each VPN required engaging with a different network provider in turn and it took several months to finish the whole project.

Adding DR doubles the number of connections required for each Datacentre duplicated.  So in the above situation a full DR solution could require 25 VPNs.

Each connection into a component in a datacentre requires a firewall rule to open up the port, and routing can get complicated.  It can be improved by adding a gateway component in the datacentre.  The gateway component handles all the traffic internal to the datacentre and can do simple protocol conversion.  This simplifies routing and keeps all the connection rules in one place.  The gateway component can be just as secure as a firewall and is a lot more flexible.  The gateway component can refuse non-SSL traffic and then it removes the need for VPNs.

This gives a pointer to what a more comprehensive solution might look like.

There are a number of rules that apply to cloud networking

1. TCP/IP is flexible and scales well but provides poor security.
2. Any *aaS provided networking security option reduces flexibility to integrate with other providers.
3. VPNs do NOT scale.
4. Firewalls are very good at blocking agile delivery processes.
5. Any security solution needs to provide/utilise Identity and Access Management.
6. One layer of (state of the art) encryption is sufficient for most purposes (no need for SSL across VPNs).
7. A solution that combines IAM with encryption and firewalls across the internet gives the security of VPNs & firewalls without many of the downsides.

The answer is provided by some sort of Software Defined Perimeter solution.  This is an emerging standard with some players providing good tools.  Access is managed by user or device, with all configuration in one place (e.g. LDAP).  There is no need to manage devices separately from applications.

SDP uses identity to control network access.  A controller provides a grant token to a specific user.  The network denies access to clients without a valid and applicable token.  An existing network can be brought into SDP with an SDP-aware gateway device.  Cloud providers (e.g. Azure) can offer SDP built into platform.

One advantage of SDP is you can have overlapping security zones and use standard internet protocols to provide infinite flexibility and scale.  An individual component can incorporate its own SDP controller or an SDP controller can control access to all nodes within a secure network segment.  An SDP controller can be part of several perimeters simultaneously.

Single Sign On (SSO) can be baked into the solution for no extra cost.  The access token identifies the user and the same claims that provide network access can also authorise individual services.  On the other hand legacy services with their own identity solutions will still work in an SDP without using SSO.

It may be some time before enough *aaS providers provide compatible solutions.  An SDP can be built from existing components, but an integrated solution is easier to manage.

I haven’t managed to implement this for any of my clients yet.  It is not just a question of putting in the infrastructure, but it is also a change of mindset.  The network providers have to let go of the idea that they can control security with firewalls and IP-based whitelists.  Identity management becomes central to security as it should be.

Some links about SDP

https://en.wikipedia.org/wiki/Software_Defined_Perimeter

https://cloudsecurityalliance.org/group/software-defined-perimeter//#_overview

A provider of SDP solutions for reference

https://www.cyxtera.com/security-analytics/appgate-sdp

Our clients have different requirements with regard to design.  Some want signed-off design documents before starting development others are satisfied with as-built documents and some think even that is overkill.  Who is right?  Or does it depend on circumstances?

Why design?

Everything needs to be designed even if it is just made up on the fly by the developer(s).  Do we want to document the design?

Design is a conversation between the various stakeholders in the project – present and future.  It may take the form of a formal design document, or it may be 3 people standing around a whiteboard.  The important point is that all finish with a shared understanding of what is to be built and why.  The needs of current participants are easily satisfied, but what about future needs?  Does the design collateral help the people that need to maintain/extend the software?  What happens if someone leaves and takes their design understanding with them? 

Advantages of Formal Design Documents

In formal engagements a signed-off design document forms the basis of a contract between the project sponsor and the developers.  The delivered software is tested against the requirements, but code-reviews are matched to the design.  The design can be reviewed in advance to see that the planned approach meets the needs of the project and fits the infrastructure before the expense of building is incurred, and this can avoid costly rework.

Where a large number of different parties are involved (business, infrastructure, networks, application developers, testers etc) a formal design document gives everyone a clear picture of what their tasks are and how they are matched to the needs of the other parties.  it allows a project manager to allocate work and check progress.

For enterprise requirements (e.g. security, performance, non-interference with other projects etc) a design document gives peripheral actors a chance to have their input.  This is important where strong governance processes are in play.  Everyone can have confidence that their needs have been considered before signing off.

The design document provides a place to document the design decisions that were made.  It is important for people who come later to understand the reasons for choosing various options.  This avoids relitigating decisions but also allows a re-examination of the options when conditions change.

Advantages of Informal Design

in smaller projects a design document may not be needed.  A daily standup can provide a forum to discuss any design decisions required.  The outcome should be recorded in the project backlog.  Comments in the code and/or scripts should be used liberally to allow future participants (or current ones with non-exceptional memories) to understand why things are done.  This can provide the needs of documented design without the overheads.  

A decision can be made in the morning and incorporated in code, checked in, built and tested all the same day.  This way the documentation is always up to date.  The documentation is always available as it is saved in the CMDB with the source.  Depending on the tooling used the documentation can often be extracted (e.g. javadoc) and made available at the end of a project without the expense of developing as-built documents.

Where should design be stored?

Often organisations have formal document management or record keeping systems for design documents.  It is often difficult to find the most up-to-date version and often even the most up-to-date version is not updated during the project so doesn’t reflect what was actually built.  This can be a problem for later projects as they have to undertake an expensive discovery phase to find out what the real state is.  Mature organisations can handle this, and it may be correct for them.

In general the documentation should be stored in the CMDB along with the code.  The same versioning/branching/tagging processes that make source code management easy, ensure that the documentation matches the deployed artefacts.  However, they don’t ensure that it is up-to-date.  A design document should always be supplemented by access to code and deployed artefacts.  

A good project-close-out process will have a supplementary document describing what was actually built.  This can be an appendix to the design document describing variations and reasons for them.  This can also be a separate as-built document.  At the least it should be release notes with a manifest of deployed artefacts along with where to find the (commented & versioned) code/configuration items.

Design for Integration

Integration projects have particular needs.  There are always several different products involved.  A clearly defined interface is almost always required up-front.

If new integration applications are required then the project looks like any software project with infrastructure, software, networking requirements.  The organisation’s normal design processes are used.

For service development, the design needs to articulate the different parties involved in the service and how they interact.  Parts of the design (e.g orchestration, mediation) are often dependent on the product set used as they will normally have graphical design tools that match design to implementation.  The interface and data design will usually use some sort of entity design tool like Sparx EA.

It is useful to have a catalogue of services in use and how they interact.  This can be a spreadsheet, but often the linkages are more involved and a 2 dimensional table cannot easily represent them.  A graph database may be an option to capture all the dependencies.

Conclusion

There is no right answer for how to document design.  That is no excuse for assuming that no design is necessary.  Sometimes it is only after the project is finished (and the next one underway) that you know whether your design strategy has been successful.

One thing is always true.  Design is never “finished”.  Even in a waterfall process with signed-off designs before coding starts there will always be further design decisions to be made as the project proceeds.  the design process should recognise this and make sure that whatever is produced is still of value at the end of the project.

The external consultant is in an unenviable position.  We come from outside an organisation that is not performing well and tell them how to fix their problems.  In so doing we come up against politics and personalities.  We give busy people more work.  We threaten fiefdoms and islands of incompetence.  Sometimes we find people that are desperate for solutions to problems that are not in the scope of the consultancy.

Why do we do it?

• We want to make a difference.
• We have skills to offer that most companies don’t need to have on their staff.
• We learn a lot from our clients.
• We get a variety of work that we couldn’t get otherwise.
• We meet lots of people.
• We travel and experience different environments.
• We get to work within deadlines.

A consultant can help a company with a particular aspect of their business that is struggling or not making progress.  We start by getting to know the clients and how they operate.  We talk to as many people as we can and devour the contents of their content management systems.  Right through the engagement we are still learning new things about the business, the management, the roles and the landscape.  We document the weaknesses (and strengths), agree a goal state and formulate a plan to get there.

For us as integration specialists it is usually about data, and how it is handled, managed, owned, maintained, transformed, transferred, described, synchronised, cleaned, and maybe even disposed of.  We come into organisations where integration is an expensive afterthought and leave them with an understanding that it needs to be baked into projects from the start.  We help to imbue them with an “API first” mentality that means that no software is purchased or developed unless it comes with integration points and a clear data model.

Our first responsibility is to satisfy the goals of the client for the engagement.  Often, however, we are able to suggest additional goals that are of great value to them.  Most clients are only too aware of their shortcomings when they come to us.  We are often able to point out strengths that they didn’t know about.  We focus on the outcome rather than worry too much about what people are doing wrong.  If we get the process right, people will find the right way easier than any other.

“Getting buy-in” and “bringing people along for the journey” are clichés but they describe accurately our way of operating.  We need to be aware of what people want from their work and help them achieve it.  Even the most disengaged employees can be enthused when they see that they are listened to and can help to make a difference.  The engagement is not only about the CxOs (although they pay the bills).  A successful engagement leaves the organisation healthier and the staff happier.

So if we are invited into your workplace come and say hello.  We will listen to you and see what we can do to make your work more effective and more valued.

The next certification I plan to do (before the end of August) is the IBM cloud architect exam.  I have a free voucher for the exam.

http://www-03.ibm.com/certify/tests/eduC5050-280.shtml

This is partly general cloud knowledge but to make it harder it needs quite detailed knowledge of the IBM cloud management products and the IBM CCMP-RA (Cloud Computing Management Platform –  Reference Architecture).

So I shall be looking at TSAM, TUAM, ISDM and Cloudburst even though I don’t think I will ever use them in anger.

This is a java program that used to display gnome and KDE menus on Linux desktops.  It was designed to be useful with very lightweight windows managers like icewm, which didn’t have menus by default.  It could be useful with unity with the right environment variables set.

If you find this and think it might be useful send me a message.

readmenu_0.6.2.tar

I actually wrote it to understand freedesktop.org.  It is not great java.

This blog is to capture some of the challenges in building a new home server.  The server is to act as the DMZ and firewalls for the home network.  I have a cable modem with a fixed IP (IP4) address that the new server plugs into.  All my home computing equipment, computers, WIFI router, network printer etc plug into a network switch at the back.

The server acts as

• Firewall external and internal
• DNS server (it was to serve as authority for my domains but Vodafone seems to block UDP DNS queries from outside it’s network)
• Router
• LAMP stack (Apache2 plus MySQL plus PHP/Perl running on Linux)
• Email server (SMTP + POP3/IMAP)

Getting these set up is not so difficult but I decided to try using ISPConfig3 to manage them.  ISPConfig This is a tool that makes it look like you are running an ISP and you can easily provision web sites, and email accounts.  It has some functionality that I don’t need and some features don’t quite work as intended, but in general it makes it easier to manage everything for multiple users.

I also installed wordpress for this blog and for all the users.  The ungrateful people aren’t rushing to create content.