Tag Archives: deployment

Security Vulnerabilities in Solution Deployment

04 Saturday Jan 2020

Posted by in development, General, Technology

≈ Leave a comment

Tags

, , , , , , , ,

To varying degrees, most techies are aware of the security vulnerabilities identified in the OWASP Top 10 (SQL Injection, trying to homebrew Identity management etc), although I still sometimes have conversations where I feel the need to get the yellow or red card out. But the bottom line is that these risks are perhaps more appreciated because it is easier to understand external entities attacking seeking direct attacks to disrupt or access information. But there are often subtler and at least more costly to repair attacks such as internal attacks and indirect attacks such as compromising software deployment mechanisms.

This, later attack Is not a new risk, as you can see from the following links, been recognised by the security community for some time (you can find academic papers going back 10+ years looking at the security risks for Yum and RPM for example).

But software is becoming ever more pervasive, we’re more aware than ever that maintaining software to the latest releases means that known vulnerabilities are closed. As a result, we have seen a proliferation in mechanisms to recognise the need to update and deploying updates. 10 years ago, updating frameworks where typically small in number and linked to vendors who could/had to invest in making the mechanisms as a secure as possible – think Microsoft, Red Hat. However we have seen this proliferate, any browser worthy of attention has automated updating let alone the wider software tools. As development has become more polyglot every language has its central repos of framework libraries (maven central, npm, chocolatey ….). Add to this the growth in multi-cloud and emphasis on micro deployments to support microservices and the deployment landscape gets larger and ever more complex and therefore vulnerable.

What to do?

Continue reading →

Oracle PaaS – the Good and opportunities to get better

19 Saturday Mar 2016

Posted by in General, Java Cloud, Oracle, Technology

≈ Leave a comment

Tags

, , , , , ,

IMG_0180Although Oracle have been late to the cloud party they are certainly making up for it, by bringing products to the cloud at an amazing pace, and using their core products to build out new offerings at a rate that will mean they will at least catch  all the competition across  the breadth of PaaS very quickly.

When it comes to taking on Oracle PaaS  it does have  some quirks, some relate to Oracle’s normal licensing approach, and others I’m told relate to the way US accounting has to work when it comes to realised revenue. A couple of other characteristics I suspect are linked to the fact that the infrastructure for Oracle’s cloud is still being rolled out and grown for capacity.

So firstly the carry over – well outside of a trial account you need to agree and sign a general agreement which provides an overarching legal framework defining terms, conditions and liabilities. This makes dealing with each subsequent purchase a little simpler. Rather than purchasing services as you go, you then purchase credits from Oracle which have a maximum life of 1 year. This does mean you’re not got a pure OPEX spend model – although you do stand a chance of negotiating a better deal as the numbers are naturally bigger. As part of the agreement you’ll get a rate card, so different services cost different amounts – for example a standard edition database will cost x and an enterprise high performance version will cost a bit more. The credits are for specific product families such as SaaS products, products in the PaaS domain for example document cloud, Java cloud, SOA and so on. But make sure the products you might want are in the families you get credits for, there is the odd surprise for example MBaaS isn’t in the same family as the integration products.

In addition your negotiation you need to consider whether  services are in metered or unmetered models.  Unmetered means you agree a level of capacity for the year. This will obviously work out cheaper than a metered model where you can use up your credits as you choose, with different metering rates – for example hourly and monthly. When this was first explained it looked really good for dealing with the situation of having a baseline demand which could be unmetered and then purchasing metered services to capacity burst. Sadly this isn’t possible out of the box. I suspect because of the way Oracle cloud allocates workload to different work domains. So bursting workload would have to be done as if you’re bursting in 2 different clouds. So if you have a dynamic load you either go unmetered to your maximum demand or metered for everything. Either way you’re not getting the best in terms of cost management.  I have to admit I don’t know whether the likes of AWS and Azure when you enter into long term agreements have the same challenges.

One the positive side, with the credits you can then purchase a broad range of configurations of products from just ADB schema all the way a full size  Exadata setup. So performing PoCs is pretty easy and figuring out scaling just means burning your credits quickly and instantiating more capacity.

Before getting into instantiating your cloud instances you’d best  setup access controls to allow people access controls to creating instances. Then you can start creating instances of the products you want. Make sure you protect your credentials as the way things are setup anyone else recovering them will be a problem.

With services such as SOA and Java you do need to go through the process of creating the different layers, storage, then the database and so on. But unlike building on premise each step only requires a couple of clicks and your done. To put it into context the first time I built a small footprint 11g environment took me a couple of days to work my way through on my own create a DB, deploy RCU,Weblogic, SOA and AIA foundation (no load balancing or security etc) and was no way near secure as a cloud instance. Oracle PaaS in three hours we:

  • Meet our Customer Success Manager (more on this shortly)
  • Got the utilities such as putty installed on my laptop
  •  Walked through putty’s key generation quirks and how to avoid the gotchyas
  • being walked through the process, of setting up management rights to our credits and instance creation
  • Instaniated storage, debated on the DB option to use, created the SOA CS instance with OSB, a load balancer and configured SSH security and web access routes to our cloud. Plus setup my developers
  • Had a couple cups of coffee and ordered lunch

With SOA CS and atleast some of the other cloud offerings you also get SSH access to the OS so you can tinker and tune your SOA container and Weblogic etc. Some would argue that totally undermines the ideal of PaaS and that exploiting such a capability means you can end up customising your deployment to the point it will break the moment an update or patch comes along. So it is very double edged. In my mind (but I’m a techie at heart so seeing the engine running is always interesting) it’s good, but must be handled with great care. As they say – with great freedom comes great responsibility.

One of the real wins is that Oracle allocate customers a Cloud Success Manager who are tasked with enabling you to use the Oracle cloud – any problems, guidance needed can be addressed through these people. A cynic might say they exist to help you spend money which becomes released revenue. But our experience is the CSMs are genuinely enthusiastic and helpful  – answering questions at 6pm on a Friday (despite my school boy error).

So in our experience so far I’d suggest Oracle could do two things to really make a big advancement – commercially atleast:

  • Allow payments to be made on a reoccurring model as an alternative to the credits model, perhaps this approach restricts you to metered only services
  • Allow metered and unmetered services to be utilised together – perhaps as a stretched cluster mentality.

This was first made available at https://community.oracle.com/groups/united-kingdom-user-group/blog/2016/03/25/starting-with-oracles-soa-cs 

Deployment considerations for Oracle Product Hub

09 Wednesday Sep 2015

Posted by in General, Oracle, Technology

≈ Leave a comment

Tags

, , , , ,

Aside from being big users of Oracle Middleware we use  make use of a range of Oracle application capabilities from the EBusiness Suite family. This includes several of the ‘hub’ products such as Product Data Hub which is central to our Master Data Management strategy for product data definition and creation. A commitment to remove all the different components in the legacy estate that can author or modify product data was made and has been rolled out – not all legacy authoring solutions have been decommissioned although this is more the nature of our legacy deployment strategy.

When we setup PDH the organisation went through a lot of internal debate on whether to deploy PDH as part of our core transactional  EBusiness Suite which performs all our accounting (and a lot more complex than may appear to be) or to adopt a separate deployment approach and keep the instances in sync using the Product Data MDM Process Integration Pack (PIP) which includes an extension to integrate with EBusiness. This later approach prevailed. However we are now in a place where we are having to re-examine this decision as a result of the PIP’s EBusiness extension hitting end of life (Oracle’s declared position being that the extension has so little adoption that it is economically not sensible to maintain it).

Rather than drag through our decision history, I thought it might be insightful to share the considerations being made on how do we go forward. So what are the perceived options? We see it as:

  1. Retain the deployment split and taken on the responsibility of maintaining the PIP
  2. As PDH is a discrete solution we could take the hit of adopting the Fusion Applications version of Product Data Hub and solve the synchronisation through the co-existence strategy
  3. Merge PDH into our main transactional EBusiness instance and remove the integration challenge by eliminating the need for it
  4. Build an alternate integration solution through the use of something like Golden Gate.

Clearly several of these options challenge the reasoning for separating the instances in the first place. So it is worth looking at the arguments for the separation and against it.

The key factors for separate instances:

  • System workloads in the transactional solution (for example end of month or year process runs) could impact user experience and productivity around the work of product data management. If this is the case and you can share the data but isolate the servers you will see a benefit
  • PDH and other hub solutions have dependencies on the core EBusiness suite, so if you want to capitalise on the improvements around the hub capability by upgrading, then isolating the instance minimises the upgrade depends considerations. If the hub was part of an EBusiness deployment with many components such as billing, manufacturing etc there is potentially a complex dependency chain to be resolved and upgrade activity that may become necessary with all the regression testing etc to be addressed with it.

The factors for keeping everything as one large EBusiness suite are:

  • The co-location of the hub and other features means that if you product authoring processes are complex and result in dependencies within the setup of other modules for example you want to align activities so buyers can both author the product data but also work with the purchasing processes you either have a multi phase authoring process – PDH to author the SKU which is distributed and then enriched within the other EBusiness instance of you end up with more modules in your hub instance and a data synchronisation challenge greater than can be resolved by the PIP.
  • remove the need for the additional licensed components – I.e. The PIP (therefore AIA foundation pack, SOA Suite, Weblogic,  OEM SOA Suite  monitoring etc).

The Fusion apps option creates some interesting questions. So the messaging around Fusion is that you can migrate from the non Fusion environments in a phased approach through the idea of co-existance (effectively data replication and transformation). However, despite the fact Fusion apps are maturing, the capability atleast here we’re told this green, although the migration process is well established as a mix of automation and manual process all packaged up as a consulting engagement. In addition to this the AIA Product MDM connector which supports EBusiness needs some small changes to work with the Fusion application.

Why even look at Fusion, aside from we know that Fusion is Oracle’s long term strategic product, from the information provided to us, it has a number of handy features for us that are unlikely to be retrofitted to the EBusiness product.

Ansible Book Review Part 4

14 Saturday Mar 2015

Posted by in Book Reviews, Books, Packt, Technology

≈ 1 Comment

Tags

, , , , , , , , , , , , , ,

This the final part of the detailed look at Packt book, Learning Ansible. As the book says in the opening to chapter 6 we’re into the back straight, into the final mile. The first of  two final  chapters look at provisioning of platforms on Amazon AWS, DigitalOcean and the use of the very hip and cool Docker plus updating your inventory of systems given that we have dynamically introduced new ones.  The approach is illustrated by not only instantiating servers but delivering a configured Hadoop cluster. As with everything else we’ve seen in Ansible there isn’t a standardised approach to all IaaS platforms as that restricts you the lowest common denominator which is contrary to Ansible goals described early on. But deploying the Hadoop elements on the two cloud IaaS providers is common.  Although the chapter is pretty short, I did have to read through this more carefully, as the book leverages a lot of demonstrated features from previous chapters (configuration arrays etc) which meant seeing the key element of the interaction with AWS was harder. It does mean if you tried diving into this chapter straight away, although not impossible does require a bit more investment from the reader to see all the value points. That said it is great to see through the use of the various features how easy to setup the provisioning in the cloud is, and the inventory update. Perhaps the win would have been to just so the simple provision and then the clever approach.

Chapter 7 focuses on Deployment. When I read this, I was a little nonplussed, hadn’t we been reading about this in the previous 6 chapters. But when you look at the definition provided:

“To position (troops) in readiness for combat, as along a front or line.”
Excerpt From: “Learning Ansible.” Packt Publishing. 

You can start to see the true target of what we’re really thinking about, which is the process of going from software build to production readiness. So having  gone through the software packaging activities you need to orchestrate the deployment across potentially multiple servers across a server farm. This orchestration piece is really just pulling together everything that has been explained before but also share some Ansible best practise. Then finally an examination of the Ansible approach for the nodes to pull deployments and updates.

The final piece of the book is an Appendix which looks at the work to bring Ansible to the Windows platform, Ansible Galaxy and Ansible Tower.  Ansible Galaxy is a repository of roles build by the Ansible community. Ansible Tower provides a web front end to the Ansible server. The Tower product is the commercial side of the Ansible company – and effectively sales here fund the full time Ansible development effort.

So to summarise …

The Learning Ansible book explains from first principles to the very rich capabilities of building packaging software, instantiating cloud servers or containers through to configuring systems and deploying applications into new environments; and then capturing instantiated system details into the Ansible inventory. How Ansible compares with the more established solutions in this space in the form of Puppet and Chef is discussed, and the pros and cons of the different tools. All the way through, the books has been written in an easy engaging manner. You might even say wonderfully written. The examples are very good with the possible exception of 2 cases (just merely good in my opinion), the examples are supported with very clear explanations that demonstrate the power of the Ansible product. Even if you choose not to use Ansible, this book does an excellent job of showing the value of not resorting to the ‘black art’ of system build and configuration and suggesting good ways to realising automation of this kind of activity, in many place undoubtedly thought provoking

Prior Review Parts: